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

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Allowing extensions to find out the OIDs of their member objects
Дата
Msg-id 8736pl3r8f.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Allowing extensions to find out the OIDs of their member objects  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Rare SSL failures on eelpout
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: add_partial_path() may remove dominated path but still in use