On Tue, Sep 25, 2012 at 10:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
