On Fri, Jan 15, 2016 at 7:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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:
How do these triggers come to be?
> * «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.
Agreed. The triggers the extension creates are not part of the extension itself and thus should not be removed even if the extension itself is removed.
> * 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?
Also agreed - pending an answer to my question. Restoration involves recreating the state of the database without "executing" things. It is assumed that those things not directly created as part of executing "CREATE EXTENSION" are instead created by "executing" things located in the extension (e.g., functions) and thus direct re-creation has to occur since there is no mechanism to execute during restoration.
If there is some sort of catalog-driven user-space population going on the selection criteria should omit from selection any objects already affected.
This is a bunch of hand-waving, though. It would help to have a concrete use-case to discuss explicitly rather than espouse theory.
I am not familiar enough with the dependency and extension internals to comment on the merit of a new kind of dependency type behaving as described. It sounds like it would allow for a more accurate description of the internal dependencies of the database - which is good absent any kind of cost consideration.
