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-28T19:24:20Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2020-10-28 14:49:06 -0400, Tom Lane wrote: >> 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? Nah. What I'm imagining is just that pg_type.h contains #ifdef EXPOSE_TO_CLIENT_CODE /* * Backwards compatibility for ancient random spellings of OID macros. * Don't use these macros in new code. */ #define CASHOID MONEYOID #define LSNOID PG_LSNOID #endif and then the negotiation here is only about whether to make this list longer. We don't need to complicate genbki.pl with a new facility. 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