On 09/25/2012 08:56 PM, Robert Haas wrote:
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
