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 length. We
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 interplay of the
array
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
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 [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 present
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
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
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
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 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
10 matches
Mail list logo
