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

From Andres Freund
Subject Re: duplicate function oid symbols
Date
Msg-id 20201028182204.tn7gy46tk5ujlatq@alap3.anarazel.de
Whole thread Raw
In response to Re: duplicate function oid symbols  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: duplicate function oid symbols  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

Thanks for fixing the HEAP_TABLE_AM_HANDLER_OID one.

On 2020-10-28 14:08:28 -0400, John Naylor wrote:
> > 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.

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

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: document pg_settings view doesn't display custom options
Next
From: Bruce Momjian
Date:
Subject: Re: Internal key management system