From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Dave Cramer <davecramer(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-03-30 19:40:12 |
Message-ID: | dd730387ca62e6450071bcfa6daf1d665adcf4f4.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2023-03-30 at 07:06 -0500, Merlin Moncure wrote:
> This ought to be impossible IMO. All libpq routines except PQexec
> have an explicit expectation on format (via resultformat parameter)
> that should not be overridden. PQexec ought to be explicitly
> documented and wired to only request text format data.
Right now it's clearly documented[1] which formats will be returned for
a given Bind message. That can be seen as the root of the problem with
psql -- we are breaking the protocol by returning binary when psql can
rightfully expect text.
It is a minor break, because something needed to send the "SET
binary_formats='...'" command, but the protocol docs would need to be
updated for sure.
> 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.
Regards,
Jeff Davis
[1]
https://www.postgresql.org/docs/current/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-BIND
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2023-03-30 19:45:41 | Re: Transparent column encryption |
Previous Message | Daniel Gustafsson | 2023-03-30 19:26:47 | Re: Should vacuum process config file reload more often |