Re: Oid registry - Mailing list pgsql-hackers

I'm also implementing an extension where direct access to non-fixed OIDs
(i.e. no catalog cache lookup by name) would be very helpful. I spent some
time thinking about a workaround that makes OID registry unnecessary.
How about the following?

1. Add a new varlena column to pg_proc catalog table, say 
'ext_types',containing
C array of OIDs.

2. Let each extension declare requirements like the following in its 
configuration
files:

"I expect <some type's name> type at 0-th position of 'ext_types' array."
"I expect <other type's name> type at 1-st position of 'ext_types' array."
etc.

3. Ensure that CREATE EXTENSION command reads all these type names, 
finds the
appropriate OIDs in pg_type and puts them to the appropriate position in 
the 'ext_types'
column for each function of the new extension (while in-core types would 
have it set to
NULL of course).

4. Implement a macro to get the 0-th, 1-st, etc. value from 
pg_proc.ext_types (via FMGR).

Is there any serious circumstance I forgot or does it seem to be e.g. 
too invasive?

Kind regards,
Tony H.

On 09/25/2012 12:59 AM, Andrew Dunstan wrote:
> This rather overdue mail arises out the developer's meeting back in 
> May, where we discussed an item I raised suggesting an Oid registry.
>
> The idea came from some difficulties I encountered when I did the 
> backport of the JSON work we did in 9.2 to 9.1, but has wider 
> application. Say someone writes an extension that defines type A. You 
> want to write an extension that takes advantage of that type, but it's 
> difficult if you don't know the type's Oid, and of course currently 
> there is no way of knowing for sure what it is unless it's a builtin 
> type. 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);
>
> I'm not sure what objects we would need this for other than types, but 
> CREATE TYPE would be a good start anyway.
>
> 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.
>
> thoughts?
>
> If there is general agreement I want to get working on this fairly soon.
>
> cheers
>
> andrew
>
>
>
>