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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dave Cramer <davecramer(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Subject: Re: Request for comment on setting binary format output per session
Date: 2023-03-20 19:09:08
Message-ID: 963304.1679339348@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2023-03-20 19:09:50 Re: Request for comment on setting binary format output per session
Previous Message Gregory Stark (as CFM) 2023-03-20 18:53:57 Re: Eliminating SPI from RI triggers - take 2