Skip site navigation (1) Skip section navigation (2)

Re: Oid registry

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Oid registry
Date: 2012-09-26 14:08:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 09/25/2012 08:56 PM, Robert Haas wrote:
> On Tue, Sep 25, 2012 at 10:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>> Given your previous comments, perhaps we could just start handing out
>>> Oids (if there is any demand) numbered, say, 9000 and up. That should
>>> keep us well clear of any existing use.
>> No, I think you missed my point entirely: handing out OIDs at the top
>> of the manual assignment range is approximately the worst possible
>> scenario.  I foresee having to someday move FirstBootstrapObjectId
>> down to 9000, or 8000, or even less, to cope with growth of the
>> auto-assigned OID set.  So we need to keep manually assigned OIDs
>> reasonably compact near the bottom of the range, and it doesn't matter
>> at all whether such OIDs are used internally or reserved for external
>> developers.  Nor do I see a need for such reserved OIDs to "look
>> different" from internally-used OIDs.  Reserved is reserved.
> I'm not sure how much anyone cares, but just in case anyone does... it
> would be mighty useful to EnterpriseDB to have a range of OIDs that
> are guarantee not to be assigned to anyone else, because we're
> maintaining a fork of PostgreSQL that regularly merges with the
> mainline.  We're actually likely to get crunched in our fork well
> before PostgreSQL itself does.  There are enough other forks of
> PostgreSQL out there that there may other people who are in a similar
> situation, though I am not sure how much we want to cater to people
> doing such things.  That having been said, I can't really see how it
> would be practical anyway unless we raise the 16384 lower limit for
> user-assigned OIDs considerably.   And I'm not sure how to do that
> without breaking pg_upgrade.

How many would EDB need for it to be useful?

> I am somewhat opposed to the idea of an OID registry.  I can't see why
> the space of things people want to reserve OIDs for would be only tens
> rather than thousands.  There are surely plenty of extensions that
> would like to depend on specific other extensions, or on core.  If we
> legislate that hard-coded OIDs are the way to do that, I think we're
> going to end up with a lot of 'em.

Maybe you have a better feel than I do for how many live addon types are 
out there. Maybe there are hundreds or thousands, but if there are I am 
blissfully unaware of them.

I did like the alternative idea upthread of UUIDs for types which would 
give them a virtually unlimited space.



In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-09-26 14:08:56
Subject: Re: system_information.triggers & truncate triggers
Previous:From: Tom LaneDate: 2012-09-26 14:07:24
Subject: Re: htup header reorganization breaks many extension modules

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group