On Wed, Sep 26, 2012 at 10:08 AM, Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
