On Tue, Apr 8, 2008 at 2:49 PM, Andrew Dunstan <andrew@dunslane.net> 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
