Moshe Jacobson <moshe@xxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
