Re: Oid registry

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Oid registry
Date: 2012-09-25 02:39:11
Message-ID: 5061194F.4000304@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 09/24/2012 09:24 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2012-09-25 02:50:48 Re: Doc patch to note which system catalogs have oids
Previous Message Michael Paquier 2012-09-25 02:37:05 Re: pg_reorg in core?