On Wed, 4 Oct 2023 at 10:17, Peter Eisentraut <pe...@eisentraut.org> wrote:
> On 31.07.23 18:27, Dave Cramer wrote: > > On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson <dan...@yesql.se > > <mailto:dan...@yesql.se>> wrote: > > > > > On 25 Apr 2023, at 16:47, Dave Cramer <davecra...@gmail.com > > <mailto:davecra...@gmail.com>> wrote: > > > > > Patch attached with comments removed > > > > This patch no longer applies, please submit a rebased version on top > > of HEAD. > > > > > > Rebased see attached > > I have studied this thread now. It seems it has gone through the same > progression with the same (non-)result as my original patch on the subject. > > I have a few intermediate conclusions: > > - Doing it with a GUC is challenging. It's questionable layering to > have the GUC system control protocol behavior. It would allow weird > behavior where a GUC set, maybe for a user or a database, would confuse, > say, psql or pg_dump. We probably should make some of those more robust > in any case. Also, handling of GUCs through connection poolers is a > challenge. It does work, but it's more like opt-in, and so can't be > fully relied on for protocol correctness. > > - Doing it with a session-level protocol-level setting is challenging. > We currently don't have that kind of thing. It's not clear how > connection poolers would/should handle it. Someone would have to work > all this out before this could be used. > > - In either case, there are issues like what if there is a connection > pooler and types have different OIDs in different databases. (Or, > similarly, an extension is upgraded during the lifetime of a session and > a type's OID changes.) Also, maybe, what if types are in different > schemas on different databases. > > - We could avoid some of the session-state issues by doing this per > request, like extending the Bind message somehow by appending the list > of types to be sent in binary. But the JDBC driver currently lists 24 > types for which it supports binary, so that would require adding 24*4=96 > bytes per request, which seems untenable. > > I think intuitively, this facility ought to work like client_encoding. > There, the client declares its capabilities, and the server has to > format the output according to the client's capabilities. That works, > and it also works through connection poolers. (It is a GUC.) If we can > model it like that as closely as possible, then we have a chance of > getting it working reliably. Notably, the value space for > client_encoding is a globally known fixed list of strings. We need to > figure out what is the right way to globally identify types, like either > by fully-qualified name, by base name, some combination, how does it > work with extensions, or do we need a new mechanism like UUIDs. I think > that is something we need to work out, no matter which protocol > mechanism we end up using. > So how is this different than the GUC that I proposed ? Dave
