Re: Oid registry

Andrew Dunstan <andrew@dunslane.net> writes:
> ...  So the proposal is to have an Oid registry, in which authors could 
> in effect reserve an Oid (or a couple of Oids) for a type. We would 
> guarantee that these Oids would be reserved in just the same way Oids 
> for builtins are reserved, and #define symbolic constants for the 
> reserved Oids. To make that viable, we'd need to extend the CREATE 
> commands for any objects we could reserve Oids for to allow for the 
> specification of the Oids, somewhat like:

>     CREATE TYPE newtype ( ....) WITH (TYPEOID = 123456, TYPEARRAYOID =
>     234567);

Well, of course, it's not clear how "reserved" an OID can be if you
provide SQL syntax that allows any Joe Blow to create a type with that
OID.  The possibilities for security holes are interesting to say the
least, especially if applications blindly assume that oid 123456 *must*
be the type they think it is.

> Another suggestion that was made during the discussion was that we 
> should also reserve a range of Oids for private use, and guarantee that 
> those would never be allocated, somewhat analogously to RFC1918 IP 
> addresses.

Likewise, "would never be allocated" and "we'll provide syntax that does
it trivially" seem a bit at odds.

Another point to think about is that it's a few years too late to
guarantee that any particular OID above 16384 is unused; we can't
do that now without possibly breaking pg_upgrade-ability of existing
databases.  While we could hand out some subrange of the OIDs below
that, there's not exactly a huge amount of space available.

> If there is general agreement I want to get working on this fairly soon.

Turning this into something actually useful seems to me to be a bit
harder than meets the eye.  I'm not opposed to it in principle, but the
management aspect seems much more difficult than the technical aspect.
        regards, tom lane