Re: Allowing extensions to find out the OIDs of their member objects - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Allowing extensions to find out the OIDs of their member objects
Date
Msg-id 8736pl3r8f.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Allowing extensions to find out the OIDs of their member objects  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.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)


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Rare SSL failures on eelpout
Next
From: Kohei KaiGai
Date:
Subject: Re: add_partial_path() may remove dominated path but still in use