Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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
