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
