Re: Oid registry

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