Re: Oid registry - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Oid registry
Date
Msg-id 5061194F.4000304@dunslane.net
Whole thread Raw
In response to Re: Oid registry  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Oid registry  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 09/24/2012 09:24 PM, Tom Lane wrote:
> 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.

I think this would probably be a superuser-only facility.


>
>> 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.


we seem to have a fair bit of leeway between to top numbered Oid as 
reported by unused_oids (4332) and 16384.

I would expect a private range of a few hundred to be more than 
adequate, and a range for registered Oids of a couple of thousand to 
last for many years. I'm expecting the use of this over quite a few 
years to be numbered in tens, not thousands.


cheers

andrew



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_reorg in core?
Next
From: "Karl O. Pinc"
Date:
Subject: Re: Doc patch to note which system catalogs have oids