* «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.
I dealt with both of those in BDR (and pglogical), where we create TRUNCATE triggers to capture and replicate table truncation. The triggers are created either during node creation/join by a SQL function that calls into C code, or via an event trigger on CREATE TABLE for subsequent creations.
Creating them tgisinternal gets you both properties you need IIRC. Certainly it hides them from pg_dump, which was the requirement for me.
You can't easily create a tgisinternal trigger from SQL. You can hack it but it's ugly. It's simple enough to just create from C. See:
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.
So ... kind of like tgisinternal and 'i' dependencies, but without the restriction on the object being dropped directly?
Is there any particular reason the user needs to be able to drop the created trigger directly?
Is it reasonable to endorse the use of 'i' dependencies by extensions instead?
