Re: Oid registry - Mailing list pgsql-hackers

<p dir="ltr"><br /> On Sep 27, 2012 9:52 AM, "Robert Haas" <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br /> ><br /> > On Wed, Sep 26, 2012 at
10:08AM, Andrew Dunstan <<a href="mailto:andrew@dunslane.net">andrew@dunslane.net</a>> wrote:<br /> > > How
manywould EDB need for it to be useful?<br /> ><br /> > Looks like we currently have about 160 hard-coded OIDs in
ourfork<br /> > that are not in PostgreSQL, across all catalogs.  Actually, there are<br /> > probably some
thingswe could do to reduce that number, which might be<br /> > the smarter way to go.  But taken at face value I
supposethat means<br /> > we would need a reservation of several hundred to allow for future<br /> > growth.<p
dir="ltr">I'mnot sure that's a way we really want to go down. How do we define which third party vendors would get to
reserveoids? And how many? And under what other potential terms?<p dir="ltr">Seems like we'd set ourselves up for
endlessdiscussions and bike shedding... <br /><br /><p dir="ltr">> >> I am somewhat opposed to the idea of an
OIDregistry.  I can't see why<br /> > >> the space of things people want to reserve OIDs for would be only
tens<br/> > >> rather than thousands.  There are surely plenty of extensions that<br /> > >> would
liketo depend on specific other extensions, or on core.  If we<br /> > >> legislate that hard-coded OIDs are
theway to do that, I think we're<br /> > >> going to end up with a lot of 'em.<br /> > ><br /> > >
Maybeyou have a better feel than I do for how many live addon types are out<br /> > > there. Maybe there are
hundredsor thousands, but if there are I am<br /> > > blissfully unaware of them.<br /> ><br /> > Well,
that'sa fair point.  There probably aren't.  But then again<p dir="ltr">There are probably more than we know. Many many
internalthings at different organizations. <br /><p dir="ltr">> the proposed registry wouldn't only cover live
projects. We'd<br /> > probably have a decent number of people say: I can't do what I want<br /> > unless I have
anOID.  And then the project becomes dormant or<br /> > obsolescent but we still have the OID reservation and
there'snot<br /> > really any politically feasible way of recovering the address space.<br /> > I can't help
thinkingthat it sounds a little bit like what IANA does,<br /> > and the problems they face, except with 2^16 OIDs
insteadof 2^32 IP<br /> > addresses.  Admittedly there should be a lot less demand for type OIDs<br /> > than for
IPaddresses, but the amount of address space we can allocate<br /> > without pain is also much smaller.<p
dir="ltr">Yeah,I think that would rapidly turn into a pain point. <br /><br /><p dir="ltr">> > I did like the
alternativeidea upthread of UUIDs for types which would give<br /> > > them a virtually unlimited space.<br />
><br/> > Yeah, me too.  That doesn't require a centralized authority (hence, no<br /> > debates here about
whethera given extension is important enough to<br /> > merit an allocation of a given size), doesn't move us
furtherin the<br /> > direction of exposing the database's internal identifiers as a concept<br /> > that users
haveto care about, ad provides essentially infinite<br /> > address space.  There's more engineering work involved
butsometimes<br /> > more engineering work means a better result.<br /><p dir="ltr">Yeah, seems like it would work
muchbetter long term. <p dir="ltr">/Magnus