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