From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq support for arrays and composites |
Date: | 2008-06-09 00:10:16 |
Message-ID: | 24946.1212970216@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
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?
Also you need to spell out the error handling conventions for each of
these.
I think you missed some "free()" operations.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-06-09 00:12:15 | Re: pg_dump restore time and Foreign Keys |
Previous Message | Andrew Dunstan | 2008-06-08 23:59:46 | libpq support for arrays and composites |