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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

>> 1. easier to read and maintain

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

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

That's what I thought and I had something similar in mind except not
with numbers.

This is obviously the same situation we have with operator and function
numbers in opclasses right now, which is something I personally find
annoying: the fact that (for example) GiST operator members are assigned
some non-self-documenting number that you can only resolve by looking at
the opclass implementation to find out what it thinks the numbers mean.

--
Andrew (irc:RhodiumToad)