Re: duplicate function oid symbols
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: John Naylor <john.naylor@enterprisedb.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-10-28T18:49:06Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > I think changing type oid macro names is somewhat problematic - in > contrast to function oid macros the type macros are much more likely to > be used by client applications, e.g. for deciding whether to use binary > or text format for a type. > A quick code search shows a few references, even just within debian > packages (some are incorrect hits, others aren't): > https://codesearch.debian.net/search?q=CASHOID&literal=1&perpkg=1 Yeah, I can easily believe that for CASHOID in particular. So I'm okay with keeping that available as a handmade alias. The other extant oid_symbol entries are PGNODETREEOID PGNDISTINCTOID PGDEPENDENCIESOID PGMCVLISTOID PGDDLCOMMANDOID LSNOID EVTTRIGGEROID The only one of these that client code would plausibly be using is LSNOID, and even that is a bit of a stretch. 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. I'd suggest keeping CASHOID and LSNOID available as aliases, and renaming the rest. regards, tom lane
Commits
-
Don't use custom OID symbols in pg_type.dat, either.
- f90149e6285a 14.0 landed
-
Don't use custom OID symbols in pg_proc.dat.
- 36b93121436c 14.0 landed