Hi. 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. * More importantly, pg_dump will dump all those trigger definitions, which is inappropriate in this case because the extension will try to create them. As an experiment, I implemented "ALTER EXTENSION … ADD TRIGGER … ON …" (a few-line patch to gram.y) and taught pg_dump.c's getTriggers() to skip triggers with any 'e' dependency. That works, in the sense that DROP EXTENSION will drop the triggers (but the triggers can't be dropped on their own any more), and pg_dump will ignore them. I'm trying to find a more generally useful mechanism that addresses this problem and has a chance of being accepted upstream. Rather than overloading 'e', we could introduce a new dependency type that references an extension, but means that the dependent object should be dropped when the extension is, but it can also be dropped on its own, and pg_dump should ignore it. That would work for this case, and I can imagine it *may* be useful for other types of objects (e.g., sequences that depend on a seqam function provided by an extension, indexes that depend on index functions provided by an extension). But that leaves open the question of how exactly to record the dependency: ALTER EXTENSION … ADD … is the easiest way, but it doesn't feel right to introduce object-type-specific logic there to determine the dependency type to use. Besides, I'm not entirely comfortable with tying pg_dump behaviour so closely with the dependency, though there's some sort of precedent there with deptype = 'i'. In short, I can see some scope for improvement, but not clearly enough to make a concrete proposal. I'm hoping for advice or suggestions with a view towards submitting something to the next commitfest (2016-03). Thanks. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
