Re: duplicate function oid symbols

John Naylor <john.naylor@enterprisedb.com>

From: John Naylor <john.naylor@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-10-28T18:08:28Z
Lists: pgsql-hackers
On Wed, Oct 28, 2020 at 12:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I wondered about introducing a similar prohibition for pg_type.
>

That might be worth doing, since some of the grandfathered macros are
clustered together, which could lead to more cases creeping in as people
match new types to examples nearby.


> The only existing oid_symbol in pg_type that I think has enough
> grandfather status to be tough to change is CASHOID for "money".
> But we could imagine special-casing that with a handmade macro
>
> #define CASHOID MONEYOID
>
> and then getting rid of the oid_symbol entries.  (Or perhaps we
> could just up and nuke CASHOID too?  It's somewhat dubious that
> any outside code is really using that macro.)
>

Yeah, grepping shows that some of those aren't even used in core code. On
the other hand, the difference from the heap_am_handler case is the
standard macros don't already exist for these pg_type entries. The handmade
macro idea could be used for all eight just as easily as for one.

-- 
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Don't use custom OID symbols in pg_type.dat, either.

  2. Don't use custom OID symbols in pg_proc.dat.