Re: Oid registry

On Sep 27, 2012 9:52 AM, "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Sep 26, 2012 at 10:08 AM, Andrew Dunstan <andrew(at)dunslane(dot)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'm not sure that's a way we really want to go down. How do we define which
third party vendors would get to reserve oids? And how many? And under what
other potential terms?

Seems like we'd set ourselves up for endless discussions and bike
shedding...

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

There are probably more than we know. Many many internal things at
different organizations.

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

Yeah, I think that would rapidly turn into a pain point.

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

Yeah, seems like it would work much better long term.

/Magnus