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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
