Andrew Chernow wrote:
> Andrew Dunstan wrote:
>>
>>
>> Merlin Moncure wrote:
>>> However, due to libpq limitations, if any datatype must
>>> return text the entire result must be text (resultFormat)...this is
>>
>> I'm surprised you didn't try to address that limitation.
>>
>>
>
> That would change the existing behavior of resultFormat, although not
> terribly. Currently, the server will spit back an error if you use
> binary results but some type hasn't implemented a send/recv. Instead
> of an error, the server could "fallback" to the type's in/out routines
> and mark the column as text format.
>
> I think the "fallback" approach is more intelligent behavior but such
> a change could break libpq clients. They might be blindly ASSuming if
> the exec worked with resultFormat=1, that everything returned by
> PQgetvalue will be binary (I'm guilty of this one, prior to libpqtypes).
>
> Our patch would work with no changes because it supports text and
> binary results. So, each type handler already toggles itself based on
> PQfformat.
That makes it sound more like a protocol limitation, rather than a libpq
limitation. Or am I misunderstanding?
cheers
andrew
