Re: duplicate function oid symbols

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

Andres Freund <andres(at)anarazel(dot)de> writes:
> 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

Yeah, I can easily believe that for CASHOID in particular. So I'm
okay with keeping that available as a handmade alias. The other
extant oid_symbol entries are

PGNODETREEOID
PGNDISTINCTOID
PGDEPENDENCIESOID
PGMCVLISTOID
PGDDLCOMMANDOID
LSNOID
EVTTRIGGEROID

The only one of these that client code would plausibly be using is LSNOID,
and even that is a bit of a stretch. Moreover, this clearly shows the
effect John mentioned that people have been copying the style of adjacent
entries rather than making use of the standard oid_symbol convention like
they should --- some of these don't exist in the initial v11 version of
pg_type.dat.

I'd suggest keeping CASHOID and LSNOID available as aliases, and renaming
the rest.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2020-10-28 18:52:11 Re: Add important info about ANALYZE after create Functional Index
Previous Message John Naylor 2020-10-28 18:45:30 Re: document pg_settings view doesn't display custom options