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'
Re: dealing with extension dependencies that aren't quite 'e' |
Список | 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 по дате отправления: