Tom Lane wrote:
> Barry Lind <blind@xythos.com> writes:
>
>>Tom Lane wrote:
>>
>>>See binary cursors ...
>
>
>>Generally that is not an option. It either requires users to code to
>>postgresql specific sql syntax, or requires the driver to do it
>>magically for them.
>
>
> Fair enough. I don't see anything much wrong with a GUC option that
> says "send SELECT output in binary format". This is not really a
> protocol issue since the ASCII and BINARY choices both exist at the
> protocol level --- there is nothing in the protocol saying binary data
> can only be returned by FETCH and not by SELECT. The main problem with
> it in present releases is that binary data is architecture-dependent and
> so encouraging its general use seems like a really bad idea. But if we
> manage to get send/receive conversion routines in there, most of that
> issue would go away.
>
That would be great.
>
>>The describe request is generally only
>>done once even though you may do multiple fetchs (unlike todays protocol
>>which includes the describe information on every fetch, even if you are
>>fetching one row at a time).
>
>
> I'm less than excited about changing that, because it breaks clients
> that don't want to remember past RowDescriptions (libpq being the
> front-line victim), and it guarantees loss-of-synchronization failures
> anytime the client misassociates rowdescription with query. In exchange
> for that, we get what exactly? Fetching one row at a time is
> *guaranteed* to be inefficient. The correct response if that bothers
> you is to fetch multiple rows at a time, not to make a less robust
> protocol.
I don't feel strongly either way on this one, but IIRC the SQL standard
for cursors only specifies fetching one record at a time (at least that
is how MSSQL and DB2 implement it). Thus portable code is likely to
only fetch one record at a time. The current row description isn't too
big, but with the changes being suggested it might become so.
thanks,
--Barry
