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 f
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On 6/8/08, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>> Tom Lane wrote:
>>> Are you intending that these operations support both text and binary
>>> results?
>>
>> I'm a bit open on that.
> IMO, support for binary is critical. Because of the interpl
On 6/8/08, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > > One complicating factor I see is that there is no protocol level support
> for anything other than simple objects - each data value is simply a stream
> of bytes of a known le
>That makes it quite useless for my intended purpose.
I found no more use cases for text results after libpqtypes started to
take shape, eventhough libpqtypes supports all data types in text &
binary excluding arrays and composites. Because of this, adding a text
parser for arrays and composi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Lastly, the idea is to provide extra facilities to libpq clients
> without requiring any extra library.
Or more to the point, without requiring boatloads of new code that
only some libpq users would have any use for.
To my mind, the point of the presen
Andrew Chernow wrote:
libpqtypes already implemented this. It is a different approach but
provides the same functionality; with the inclusion of being able to
handle every data type. libpqtypes uses the PGresult API for
composites and arrays, rather than adding a new set of functions.
Andrew Dunstan wrote:
One of the areas where libpq seems to be severely lacking is in handling
arrays and composites in query results. I'd like to set about rectifying
that.
Ideally this would mean that drivers using libpq could easily and
reliably deliver such objects suitably structured i
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
One complicating factor I see is that there is no protocol level support
for anything other than simple objects - each data value is simply a
stream of bytes of a known length. We would therefore need some pretty
robust processing
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> One complicating factor I see is that there is no protocol level support
> for anything other than simple objects - each data value is simply a
> stream of bytes of a known length. We would therefore need some pretty
> robust processing to pick apart
One of the areas where libpq seems to be severely lacking is in handling
arrays and composites in query results. I'd like to set about rectifying
that.
Ideally this would mean that drivers using libpq could easily and
reliably deliver such objects suitably structured in their particular
lan
10 matches
Mail list logo
