Re: dealing with extension dependencies that aren't quite 'e'

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: dealing with extension dependencies that aren't quite 'e'
Дата
Msg-id 18108.1452869354@sss.pgh.pa.us
обсуждение исходный текст
Ответ на dealing with extension dependencies that aren't quite 'e'  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Ответы Re: dealing with extension dependencies that aren't quite 'e'  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: dealing with extension dependencies that aren't quite 'e'  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Список pgsql-hackers
Abhijit Menon-Sen <ams@2ndQuadrant.com> writes:
> I'm looking at an extension that creates some triggers (on user tables)
> dynamically (i.e., not during CREATE EXTENSION, but afterwards). The
> author has two problems with it:

> * «DROP EXTENSION ext» won't work without adding CASCADE, which is an
>   (admittedly relatively minor) inconvenience to users.

I am not sure why that's a bad thing.

> * More importantly, pg_dump will dump all those trigger definitions,
>   which is inappropriate in this case because the extension will try
>   to create them.

Or that.  Shouldn't pg_dump be expected to restore the same state
that was there before?  IOW, what is the argument that this doesn't
just represent poorly-thought-through extension behavior?
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Combining Aggregates
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Limit and inherited tables