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

From Tom Lane
Subject Re: duplicate function oid symbols
Date
Msg-id 1441954.1603910946@sss.pgh.pa.us
Whole thread Raw
In response to Re: duplicate function oid symbols  (Andres Freund <andres@anarazel.de>)
Responses Re: duplicate function oid symbols  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: document pg_settings view doesn't display custom options
Next
From: Tomas Vondra
Date:
Subject: Re: Add important info about ANALYZE after create Functional Index