Re: Allowing extensions to find out the OIDs of their member objects - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allowing extensions to find out the OIDs of their member objects
Date
Msg-id 18526.1548032740@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allowing extensions to find out the OIDs of their member objects  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> In fact I suggest that "there shall be no registries of third parties"
> be made a formal project policy.

You're a decade or two too late for that; see pg_statistic.h.

In any case, it's not like this issue applies to every extension anybody
might want to make.  Only quite advanced extensions would have any need
for the features that known-at-compile-time OIDs would help with, as shown
by the fact that everyone's gotten by without them so far.  And people who
have a reason to fly under the radar could always stick with the method of
doing object-name-based runtime lookups.

I also note that multiple people have asked for extensions to have stable
OIDs for other reasons.  Unfortunately, the most common reason is so that
client apps could hard-wire knowledge about type OIDs they see in query
results, and my proposal excludes being able to do that :-(.  But it's
not like nobody has wanted publicly-assigned OIDs before.

There may well be good technical reasons why we shouldn't go this route
(the extension upgrade problem in particular).  But your objection seems
basically political and I reject it as a valid argument.

> Seriously, this whole idea is a lazy hack. Fixed assignments? really?

Hardly lazy.  It's the most difficult approach (from our standpoint)
of the three I mentioned; but the flip side of that is it takes the
least work, and produces the most efficient code, for extension
developers.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: Allowing extensions to find out the OIDs of their member objects
Next
From: Chapman Flack
Date:
Subject: Re: PostgreSQL vs SQL/XML Standards