Re: duplicate function oid symbols

From: Andres Freund <andres(at)anarazel(dot)de>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: duplicate function oid symbols
Date: 2020-10-28 18:22:04
Message-ID: 20201028182204.tn7gy46tk5ujlatq@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-10-28 18:29:16 Re: Internal key management system
Previous Message John Naylor 2020-10-28 18:15:27 document pg_settings view doesn't display custom options