Merlin Moncure wrote:
> On Wed, Apr 9, 2008 at 8:04 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> \> Merlin Moncure wrote:
>>> However, due to libpq limitations, if any datatype must
>>> return text the entire result must be text (resultFormat)...this is
>>> also interestingly true for functions that return 'void'. So, at
>>> present, to use PQgetf, you result set must be binary.
>> I'm surprised you didn't try to address that limitation.
>
>
> whoops! we did...thinko on my part. Text results are fully supported
> save for composites and arrays.
>
> merlin
>
Yeah, currently composites and arrays only support binary results in libpqtypes. This forces any array elementType or
anymember of a composite to have a
send/recv routine. Using the "fallback to text output" approach, this
limitation on array elements and composite members would be removed.
>>That makes it sound more like a protocol limitation, rather than a>>libpq limitation. Or am I misunderstanding?
It looks like libpq, message 'T' handling in getRowDescriptions, reads a
separate format for each column off the wire. The protocol already has this
ability. The backend needs a ?minor? adjustment to make use of the existing
capability.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
