Dave Cramer
On Sat, 25 Mar 2023 at 19:06, Jeff Davis <pg...@j-davis.com> wrote: > On Thu, 2023-03-23 at 15:37 -0400, Dave Cramer wrote: > > So where do we go from here ? > > > > I can implement using type names as well as OID's > > My current thought is that you should use the protocol extension and > make type names work (in addition to OIDs) at least for fully-qualified > type names. I don't really like the GUC -- perhaps I could be convinced > it's OK, but until we find a problem with protocol extensions, it looks > like a protocol extension is the way to go here. > > Well as I said if I use any external pool that shares connections with multiple clients, some of which may not know how to decode binary data then we have to have a way to set the binary format after the connection is established. I did float the idea of using the cancel key as a unique identifier that passed with the parameter would allow setting the parameter after connection establishmen. I like Peter's idea for some kind of global identifier, but we can do > that independently at a later time. > > If search path works fine and we're all happy with it, we could also > support unqualified type names. It feels slightly off to me to use > search_path for something like that, though. > > There's still the problem about the connection pools. pgbouncer could > consider the binary formats to be an important parameter like the > database name, where the connection pooler would not mingle connections > with different settings for binary_formats. That would work, but it > would be weird because if a new version of a driver adds new binary > format support, it could cause worse connection pooling performance > until all the other drivers also support that binary format. I'm not > sure if that's a major problem or not. Another idea would be for the > connection pooler to also have a binary_formats config, and it would do > some checking to make sure all connecting clients understand some > minimal set of binary formats, so that it could still mingle the > connections. Either way, I think this is solvable by the connection > pooler. > Well that means that connection poolers have to all be fixed. There are more than just pgbouncer. Seems rather harsh that a new feature breaks a connection pooler or makes the pooler unusable. Dave
