Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers