On Fri, 6 Oct 2023 at 13:11, Peter Eisentraut <pe...@eisentraut.org> wrote: > > On 04.10.23 20:30, Dave Cramer wrote: > > 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 ? > > The last patch I see from you in this thread uses OIDs, which I have > argued is not the right solution.
Since the protocol already returns OIDs in the ParameterDescription and RowDescription messages I don't see why using OIDs for this GUC would cause any additional problems. Clients already need to know OIDs and how to encode/decode them. So I don't see a big reason why we should allow passing in "schema"."type" as well. Clients already need a mapping from typename to OID for user defined types to be able to parse ParameterDescription and RowDescription messages. With my Citus hat on: I would very much like something like the UUID or typename approach. With Citus the same user defined type can have different OIDs on each of the servers in the cluster. So it sounds like currently using a transaction pooler that does load balancing across the workers in the cluster would cause issues for user defined types. Having a cluster global unique identifier for a type within a database would be able to solve those issues. But that would require that the protocol actually sent those cluster global unique identifiers instead of OIDs. As far as I can tell similar issues would be present with zero-downtime upgrades using pg_upgrade + logical replication, and probably also in solutions like BDR. i.e. this is an issue when clients get transparently re-connected to a new host where an OIDs of user defined types might be different. So I think OIDs are a good choice for the newly proposed GUC, because that's what the protocol uses currently. But I do think it would be good to keep in mind what it would look like if we'd change the protocol to report and accept UUIDs/typenames instead of OIDs. UUIDs/typenames and OIDs have a clearly different string representation though. So, I think we could easily expand the new GUC to support both OIDs and UUIDs/typenames when we change the protocol to do so too, even when supporting just OIDs now.