Moshe Jacobson <moshe@neadwerx.com> writes:
> I've added the requisite rows to pg_depend, and I know it was correct
> because \dx+ cyanaudit (my extension) now shows all of the triggers.
> However, pg_dump still dumps them, and pg_restore still restores them,
> causing the same errors as I had before.
I don't think pg_dump believes that pg_trigger rows can belong to an
extension; and I'm dubious of the concept too. What I was wondering about
was whether those rows had proper dependencies on (a) the functions and
(b) their owning tables.
Basically what you need to end up with is
* trigger function has a membership dependency on the extension
* pg_trigger row has a normal dependency on the trigger function it uses
* pg_trigger row has an auto dependency on the table it's for
If you're using SQL commands to create the trigger then I'd expect the
latter two to be handled automatically; but it sorta sounds like you're
doing something pretty low-level and perhaps omitting these steps.
Note: depending on what it is you're trying to accomplish, it might be
saner for the pg_trigger rows to have auto dependencies on their trigger
functions. Depends whether you'd like DROP EXTENSION to complain or just
shut up and drop the triggers.
regards, tom lane
