From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, ashutosh(dot)bapat(at)enterprisedb(dot)com |
Subject: | Re: using arrays within structure in ECPG |
Date: | 2014-04-01 23:28:43 |
Message-ID: | CAHyXU0zUQeHtgVCWjJzYzhpN8u-96_8-cw-4eK+fwB_RiJRfog@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 1, 2014 at 11:50 AM, Michael Meskes <meskes(at)postgresql(dot)org> wrote:
> Hi Ashutosh,
>
>> I tried to fix the offset problem. PFA the patch. It does solve the
>> problem of setting wrong offset in ECPGdo() call.
>
> Thanks, looks correct to me.
>
>> But then there is problem of interpreting the result from server as an
>> array within array of structure. The problem is there is in
>> ecpg_get_data(). This function can not understand that the "field" is an
>> array of integers (or for that matter array of anything) and store all
>> the values in contiguous memory at the given address.
>
> I guess I know where that comes from, without actually looking at the
> code, though. Nested arrays are not supported by ecpg and the
> precompiler spits out an error message, just check preproc/type.c.
> However, in your example you have the struct essantially sandwiched
> between the arrays and the (too) simple check in that file doesn't
> notice, but because the implementation is nevertheless lacking.
>
> I'm sorry, but this sounds like a missing feature bug.
Small aside:
I've often wondered if the right long term approach is to abstract
backend type code into a shared library that both the server and
(optionally) the client would link with. That would make extending
support to exotic types in ecpg much easier.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-04-02 00:29:18 | Re: Including replication slot data in base backups |
Previous Message | Andrew Dunstan | 2014-04-01 22:07:42 | Re: json/jsonb/hstore operator precedence |