On Tue, 28 Mar 2023 at 19:01, Jeff Davis <pg...@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
