Hi, On 2020-10-28 14:49:06 -0400, Tom Lane wrote: > The other extant oid_symbol entries are > > PGNODETREEOID > PGNDISTINCTOID > PGDEPENDENCIESOID > PGMCVLISTOID > PGDDLCOMMANDOID > EVTTRIGGEROID
> The only one of these that client code would plausibly be using is LSNOID, > and even that is a bit of a stretch. There's a quite a few references to LSNOID in github code: https://github.com/search?o=desc&q=LSNOID&s=indexed&type=Code There also are a few references to the more marginal symbols above. But they look more like somebody trying to be complete. E.g. https://github.com/yugabyte/yugabyte-db/blob/8d0ef3f7f8c49a8d9bec302cdcc0c40f5d9e785b/src/postgres/src/backend/utils/misc/pg_yb_utils.c#L500 although there also is slightly more intentional looking references like https://github.com/tada/pljava/blob/63d8a5e467a9c0f626c48e9ee134a58ac308fd8e/pljava/src/main/java/org/postgresql/pljava/jdbc/SQLXMLImpl.java#L177 > Moreover, this clearly shows the > effect John mentioned that people have been copying the style of adjacent > entries rather than making use of the standard oid_symbol convention like > they should --- some of these don't exist in the initial v11 version of > pg_type.dat. Wonder if it's worth using something like 'backward_compat_oid_symbol' and rejecting plain oid_symbol references for pg_type? That'd perhaps be less likely to be copied? > I'd suggest keeping CASHOID and LSNOID available as aliases, and renaming > the rest. I don't really have an opinion on wether it's worth keepign the other aliases or not... Greetings, Andres Freund
