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: | 50630C67.104@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-09-26 14:08:56 | Re: system_information.triggers & truncate triggers |
Previous Message | Tom Lane | 2012-09-26 14:07:24 | Re: htup header reorganization breaks many extension modules |