Re: libpq support for arrays and composites

On 6/10/08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Merlin Moncure" <mmoncure@gmail.com> writes:
> > IMO, support for binary is critical.  Because of the interplay of the
> > array and composite out formats, the number of backslashes grows
> > exponentially (!) with nesting levels.  This makes text format arrays
> > unsuitable for any non-trivial operations involving arrays of
> > composites.
>
> Um ... but who cares, as long as you've got functions to wrap and unwrap
> the data for you?  Personally I wouldn't object if these were text-only;
> they'd be a whole lot more future-proof that way.

Are you truly suggesting that a format where potentially hundreds of
backslashes are sent per character of useful data is something you
would encourage users to use in a data-centric application?  This is
bloated and wasteful in the extreme!  I took one look at the output
the database produced in one application we are using with a couple of
levels of nesting and determined that the text approach was not
workable.  This was in fact the early genesis of libpqtypes.

Granted, it doesn't impact a wide range of use cases.  It's not like
the array and composite container formats are particularly
complicated.  The 'future proofing' requirements should be fairly
easily solved (as opposed to a general solution which covers the
entire range of types).

> > One alternative is to do a MAXDIM (6) argument 'getter' also taking
> > the requested dimension with perhaps some wrapping macros for
> > simplicity.  One issue with this is that it seems to suggest array
> > slicing etc. which seems more complicated than it's worth.
>
> Let's not embed MAXDIM in libpq's ABI :-(

right.  For this and other reasons I think recursing into the array
structure is the best approach...ideally using a PGresult to present
the array data.

merlin