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

From Michael Paquier
Subject Re: Allowing extensions to find out the OIDs of their member objects
Date
Msg-id 20190121091453.GA2520@paquier.xyz
Whole thread Raw
In response to Allowing extensions to find out the OIDs of their member objects  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Jan 20, 2019 at 06:50:33PM -0500, Tom Lane wrote:
> A larger issue is whether "hand out some OIDs on-demand" is a
> sustainable strategy.  I think that it is, if we encourage extensions
> to assign fixed OIDs only to objects they really need to.  In thirty-ish
> years of core PG development, we've only used up ~4200 fixed OIDs,
> and a lot of those are for functions that probably don't really need
> fixed OIDs but got one because we give one to every built-in function.
> However, if there's a big land rush to claim large chunks of OIDs,
> we might have a problem.

Hm.  Such things are a bit concerning.  There are many closed and open
extensions, so it looks hard to not create conflicts between multiple
extensions trying to get the same range of OIDs or even the same OIDs
and users willing to combine some of them.  This could mess up the
user experience.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: speeding up planning with partitions
Next
From: Fabien COELHO
Date:
Subject: Re: [PATCH] pgbench tap tests fail if the path contains a perlspecial character