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

Dave Cramer

On Mon, 20 Mar 2023 at 15:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Dave Cramer <davecramer(at)gmail(dot)com> writes:
> > On Mon, 20 Mar 2023 at 13:05, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> >> 2. Easy to confuse psql:
> >>
> >> CREATE TABLE a(d date, t timestamptz);
> >> SET format_binary='25,1082,1184';
> >> SELECT * FROM a;
> >> d | t
> >> ---+---
> >> ! |
> >> (1 row)
> >>
> >> Well I'm guessing psql doesn't know how to read date or timestamptz in
> >> binary. This is not a failing of the code.
>
> What it is is a strong suggestion that controlling this via a GUC is
> not a great choice. There are many inappropriate (wrong abstraction
> level) ways to change a GUC and thereby break a client that's not
> expecting binary output. I think Jeff's suggestion that we should
> treat this as a protocol extension might be a good idea.
>
> If I recall the protocol-extension design correctly, such a setting
> could only be set at session start, which could be annoying --- at the
> very least we'd have to tolerate entries for unrecognized data types,
> since clients couldn't be expected to have checked the list against
> the current server in advance.
>

As mentioned for connection pools we need to be able to set these after the
session starts.
I'm not sure how useful the protocol extension mechanism works given that
it can only be used on startup.

>
> regards, tom lane
>