Re: Oid registry

On 09/25/2012 08:56 PM, Robert Haas wrote:
> On Tue, Sep 25, 2012 at 10:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Andrew Dunstan <andrew@dunslane.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.

cheers

andrew