Re: Request for comment on setting binary format output per session - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: Request for comment on setting binary format output per session
Date
Msg-id CADK3HHK9XqxtVeuZvSvGtLaZK4eYFmshz5XF=cUrDmLdeZOCKw@mail.gmail.com
Whole thread Raw
In response to Re: Request for comment on setting binary format output per session  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Request for comment on setting binary format output per session  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers


On Tue, 28 Mar 2023 at 19:01, Jeff Davis <pgsql@j-davis.com> wrote:
On Tue, 2023-03-28 at 10:22 -0400, Dave Cramer wrote:
> OK, IIUC what you are proposing here is that there would be a
> separate pool for 
> database, user, and OIDs. This doesn't seem too flexible. For
> instance if I create a UDT and then want it to be returned 
> as binary then I have to reconfigure the pool to be able to accept a
> new list of OID's.

There are two ways that I could imagine the connection pool working:

1. Accept whatever clients connect, and pass along the binary_formats
setting to the outbound (server) connection. The downside here is that
if you have many different clients (or different versions) that have
different binary_formats settings, then it creates too many pools and
doesn't share well enough.
As I understand it, pools create connections before the client actually requests the connection.
This would necessitate having the binary format information in the configuration file.

I'm starting to wonder about the utility of the protocol extension mechanism? 
It would seem that you would need to add the new feature into all pools ? 

2. Some kind of configuration setting (or maybe it can be done
automatically) that organizes based on a common subset of binary
formats that many clients can understand.
 
Well that would bring us back to just providing a list of OID's of well known types as I first proposed instead of trying to accomodate UDT's 

Dave
 

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: BufmgrCommit no-op since 2008, remaining uses?
Next
From: Pavel Stehule
Date:
Subject: Re: Tab completion for AT TIME ZONE