Re: ALTER EXTENSION .. ADD/DROP weirdness

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER EXTENSION .. ADD/DROP weirdness
Дата
Msg-id 29788.1318454150@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ALTER EXTENSION .. ADD/DROP weirdness  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: ALTER EXTENSION .. ADD/DROP weirdness
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The underlying issue here is whether objects dependent on an extension
>> member should have direct dependencies on the extension too, and if not,
>> how do we prevent that? �The recordDependencyOnCurrentExtension calls
>> don't have enough information to know what to do, I think.

> After looking at this code, it seems that we've generally made that
> the caller's problem - e.g. in heap_create_with_catalog(), we skip
> recordDependencyOnCurrentExtension() if we're dealing with a composite
> type.  So I think the fix here is just to move the
> recordDependencyOnCurrentExtension() call in pg_type.c inside the
> if-block that precedes it, as in the attached patch.

Hmm.  I'm afraid that's going to break something, because I had had it
like that originally and changed it in commit
988cccc620dd8c16d77f88ede167b22056176324.  However, I'm not quite sure
*what* it will break, because it seems like in general extension
dependencies ought to act pretty nearly like owner dependencies.
In a quick look, this seems to be the only place where we're doing it
differently (without a clear reason) for recordDependencyOnOwner and
recordDependencyOnCurrentExtension.

Let me poke at it a bit more.  The proposed patch is a bit short on
comment fixes, anyway.
        regards, tom lane


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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Dumping roles improvements?
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Overhead cost of Serializable Snapshot Isolation