Re: Allowing extensions to find out the OIDs of their member objects

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> I thought about extending the extension infrastructure to provide
> Tom> some way of retrieving relevant OIDs. We could imagine, for
> Tom> instance, that an extension script has a way to say "this function
> Tom> is object number three within this extension", ...

> I suggest using string tags rather than object numbers:

Meh ... that increases the cost of individual lookups substantially.
The implementation I had in mind was that an extension would do a
once-per-session catalog lookup to fetch an array of OIDs [1], and
then individual operations would just index into that array. If what
we provide is string tags, the cost per lookup goes up by two or
three orders of magnitude, for benefits that seem pretty hypothetical.

The in-catalog representation gets a lot more complex too, as it can't
just be "oid[]". (No, I do not wish to hear the word JSON here.)

I don't buy any of your suggested benefits:

> 1. easier to read and maintain

The SQL-level API that I'm imagining would look roughly like
a command like this at the end of an extension's script:

ALTER EXTENSION extname SET MAP
OBJECT 1 IS FUNCTION foo(int, int),
OBJECT 2 IS OPERATOR +(float, float), ...

where the parts after "IS" should be able to use the same production
as for "member_object" in ALTER EXTENSION ADD/DROP. Execution of
this would replace an oid[] field in the extension's pg_extension row.
So yeah, we could replace the numbers by identifiers in this command,
but does that really buy us much maintainability? Any intelligent
extension author is going to have a C header with something like

#define MY_FUNCTION_FOO_INT_INT 1
#define MY_OPERATOR_PLUS_FLOAT_FLOAT 2

which she has to keep in sync with the ALTER SET MAP in her extension
script. Using names in the SET MAP just changes the contents of those
#defines to strings, which isn't moving the goalposts much for
maintainability.

> 2. an object might be given many tags, some of them automatically

> 3. it might make sense to provide a function that the extension can use
> to ask "is oid X one of my objects with tag 'foo'" (e.g. to match one of
> a set of related functions) in addition to looking up specific oids by
> tag

I'm not seeing that either of these have actual real-world use cases,
at least not use-cases with the same constraints that the OID mapping
problem has. In particular, we're going to have to lock down use of
the SET MAP command pretty hard, since the ability to insert a different
object than a support function thought it was calling would be an easy
security hole. That seems like it lets out many of the potential
applications of the sort of object labeling you're talking about.
(I'd also wonder why such labeling would be needed only for objects
in extensions.)

regards, tom lane

[1] The possibility of needing to flush that cache complicates this,
but it'd complicate the other thing too.