On 6/10/08, Tom Lane <[EMAIL PROTECTED]> wrote: > "Merlin Moncure" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers