Re: Oid registry - Mailing list pgsql-hackers

On Wed, Sep 26, 2012 at 10:08 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> How many would EDB need for it to be useful?

Looks like we currently have about 160 hard-coded OIDs in our fork
that are not in PostgreSQL, across all catalogs.  Actually, there are
probably some things we could do to reduce that number, which might be
the smarter way to go.  But taken at face value I suppose that means
we would need a reservation of several hundred to allow for future
growth.

>> 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.

Well, that's a fair point.  There probably aren't.  But then again,
the proposed registry wouldn't only cover live projects.  We'd
probably have a decent number of people say: I can't do what I want
unless I have an OID.  And then the project becomes dormant or
obsolescent but we still have the OID reservation and there's not
really any politically feasible way of recovering the address space.
I can't help thinking that it sounds a little bit like what IANA does,
and the problems they face, except with 2^16 OIDs instead of 2^32 IP
addresses.  Admittedly there should be a lot less demand for type OIDs
than for IP addresses, but the amount of address space we can allocate
without pain is also much smaller.

> I did like the alternative idea upthread of UUIDs for types which would give
> them a virtually unlimited space.

Yeah, me too.  That doesn't require a centralized authority (hence, no
debates here about whether a given extension is important enough to
merit an allocation of a given size), doesn't move us further in the
direction of exposing the database's internal identifiers as a concept
that users have to care about, ad provides essentially infinite
address space.  There's more engineering work involved but sometimes
more engineering work means a better result.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company