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
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 |