Re: libpq support for arrays and composites

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

In response to

Responses

Browse pgsql-hackers by date

  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