From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq support for arrays and composites |
Date: | 2008-06-09 00:33:52 |
Message-ID: | 484C7A70.3030503@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> One complicating factor I see is that there is no protocol level support
>> for anything other than simple objects - each data value is simply a
>> stream of bytes of a known length. We would therefore need some pretty
>> robust processing to pick apart structured objects.
>>
>
> Well, it's not that hard, the quoting/escaping rules for array_out and
> record_out are well defined.
>
> Are you intending that these operations support both text and binary
> results?
>
I'm a bit open on that.
> The array accessors with ... parameter lists strike me as a bit
> dangerous, because there is no way at all to verify that the caller is
> passing the expected number of dimensions. Can't that be made tighter?
>
Well, the only alternative I can think of is to make the client walk the
array one dimension at a time. Something like:
PQarray * PQgetInnerArray(PQarray * array, int dim);
then when we're down to the leaf level, we could have:
int PQgetArrayElementLength(PQarray * array, int dim);
bool PQgetArrayElementIsNull(PQarray * array, int dim);
char * PQgetArrayElement(PQarray * array, int dim);
That strikes me as somewhat more cumbersome, so I guess the question is
whether it's worth it. It probably fits the slightly clunky feel of libpq.
> Also you need to spell out the error handling conventions for each of
> these.
>
> I think you missed some "free()" operations.
>
Oh, yes, both of these are certainly true. This isn't really even a
proposal yet, more a sketch that would lead to a proposal. I'm hoping to
get some other input too, before settling this down, especially from
driver writers.
> It might also be useful to provide some functions that form an array or
> composite value from per-element strings, ie, the converse of the
> de-construction routines. Here I'd be happy to skip the binary case.
>
>
>
Yeah, that had occurred to me. Will think about it more, although it
could possibly be done as a separate project, too.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2008-06-09 00:40:31 | Re: pg_dump restore time and Foreign Keys |
Previous Message | Tom Lane | 2008-06-09 00:23:25 | Re: handling TOAST tables in autovacuum |