From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq support for arrays and composites |
Date: | 2008-06-10 15:29:17 |
Message-ID: | b42b73150806100829l22c9aecat65e746fe746a24a9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/10/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Merlin Moncure" <mmoncure(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2008-06-10 15:34:51 | Re: pg_statistics and sample size WAS: Overhauling GUCS |
Previous Message | Alvaro Herrera | 2008-06-10 15:27:57 | Re: RFD: ALTER COLUMN .. SET STORAGE COMPRESSED; |