Re: Array types

From: "John Lister" <john(dot)lister-ps(at)kickstone(dot)com>
To: "Andrew Chernow" <ac(at)esilo(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Array types
Date: 2009-04-07 19:35:07
Message-ID: BF6DDFB5B0B346AC94F9683EC6339E73@squarepi.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Does libpqtypes pass the array "over the wire" as an array? Ideally i'd like
to do this with jdbc, but might give me a pointer...

Thanks
----- Original Message -----
From: "Andrew Chernow" <ac(at)esilo(dot)com>
To: "John Lister" <john(dot)lister-ps(at)kickstone(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Sent: Tuesday, April 07, 2009 8:15 PM
Subject: Re: [HACKERS] Array types

> John Lister wrote:
>> They all return arrays as text, is it possible to configure postgresql to
>> return an array in native form (does postgresql support such a thing)?
>> This is using both the simple and extended query forms - i couldn't see a
>> way to say what return type i wanted in the protocol docs...
>>
>
> You need libpqtypes (client-side library). It requires a new 8.4 feature
> called libpq-events, but there is an 8.3 patch available. If you willing
> to patch your 8.3.5 libpq client, than this should meet your needs.
>
> Downloads: http://pgfoundry.org/projects/libpqtypes/
> Documentation: http://libpqtypes.esilo.com/
>
> For arrays, libpqtypes gives you a PGresult where each tuple is an array
> item. For composite arrays, each composite field is a PGresult field.
>
>> This would seem much better in terms of performance, both size and
>> speed(conversion).
>>
>
> That is true. Our testing has proven this. It also reduces the overall
> coding effort.
>
> --
> Andrew Chernow
> eSilo, LLC
> every bit counts
> http://www.esilo.com/
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2009-04-07 19:36:19 Re: Update PL interpreters for 8.4
Previous Message John Lister 2009-04-07 19:32:34 Re: Array types