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