Re: Request for comment on setting binary format output per session

From: Dave Cramer <davecramer(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Request for comment on setting binary format output per session
Date: 2023-04-03 16:28:50
Message-ID: CADK3HH+v50kAjTF9b2rCWzEu1ixWk31Mo-4VSR4T8RKe3GrhcQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> participating clients to receive GUC configured format. I do not

> > think that libpq's result format being able to be overridden by GUC
>> > is a good idea at all, the library has to to participate, and I
>> > think can be made to so so without adjusting the interface (say, by
>> > resultFormat = 3).
>>
>> Interesting idea. I suppose you'd need to specify 3 for all result
>> columns? That is a protocol change, but wouldn't "break" older clients.
>> The newer clients would need to make sure that they're connecting to
>> v16+, so using the protocol version alone wouldn't be enough. Hmm.
>>
>
>
So this only works with extended protocol and not simple queries.
Again, as Peter mentioned it's already easy enough to confuse psql using
binary cursors so
it makes sense to fix psql either way.

If you use resultFormat (3) I think you'd still end up doing the Describe
(which we are trying to avoid) to make sure you could receive all the
columns in binary.

Dave

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2023-04-03 16:40:49 Re: Should vacuum process config file reload more often
Previous Message Alvaro Herrera 2023-04-03 15:34:52 Re: Minimal logical decoding on standbys