Use a separate pg_depend.deptype for extension membership?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Use a separate pg_depend.deptype for extension membership?
Дата
Msg-id 16685.1296846512@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Use a separate pg_depend.deptype for extension membership?  (Andrew Dunstan <andrew@dunslane.net>)
Re: Use a separate pg_depend.deptype for extension membership?  (Robert Haas <robertmhaas@gmail.com>)
Re: Use a separate pg_depend.deptype for extension membership?  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
The extensions patch currently records that an object is part of an
extension by making a pg_depend entry with deptype 'i' (INTERNAL).
While that has the behavior we want, I wonder whether it wouldn't
be smarter in the long run to invent a new deptype for this purpose.
We do not want people confusing module membership with actual internal
dependencies, particularly not if kluges like pg_extension_flag_dump
are going to be around.  (I'm currently feeling that that function
isn't going to make it into the committed patch, but sooner or later
there are likely to be similar operations.)

The main objection I can see to a new deptype is that it might confuse
client-side code that examines pg_depend.  But adding all these internal
dependencies that don't mean quite what other internal dependencies do
would likely confuse such code in more subtle ways anyhow.

If we go with a new deptype, I was thinking of using 'm' (macro
DEPENDENCY_MEMBER) but am not set on that.  Have we been using any
particular term to refer to the objects that belong to an extension?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: Spread checkpoint sync
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: multiset patch review