Re: duplicate function oid symbols - Mailing list pgsql-hackers

From John Naylor
Subject Re: duplicate function oid symbols
Date
Msg-id CAFBsxsHFr8+wmZh8xkzdmjcJfxN+X5pmB1TOA8oOnmRutfHApA@mail.gmail.com
Whole thread Raw
In response to Re: duplicate function oid symbols  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: duplicate function oid symbols
List 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 

pgsql-hackers by date:

Previous
From: Rahila Syed
Date:
Subject: Re: [PATCH] Add `truncate` option to subscription commands
Next
From: John Naylor
Date:
Subject: document pg_settings view doesn't display custom options