On Tue, Apr 8, 2008 at 2:49 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > Better support for arrays and composites is certainly something that > > people might want, but the problem with this design is that it forces > > them to buy into a number of other decisions that they don't necessarily > > want. > > > > I could see adding four functions to libpq that create and parse > > the textual representations of arrays and records.
> Well, that was the part that interested me, so let me now speak up in favor > of better array/record support in libpq. by the way, we handle both text and binary array results...and getting things in binary is _much_ faster. not to mention text is destructive. for example, composite types in text do not return the oid of composite member fields. with our patch, since you can 'pop' a result of a returned composite, or array of composite, you have access to all that information in the result api. so I would argue that allowing text only parsing only recovers a portion of the provided functionality. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
