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
