From: | Olleg Samoylov <splarv(at)ya(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: A trigger in an extension |
Date: | 2025-02-21 06:13:26 |
Message-ID: | f7db41f4-80c5-4e4d-8380-446101ec684e@ya.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On 20.02.2025 22:30, Tom Lane wrote:
> Olleg Samoylov <splarv(at)ya(dot)ru> writes:
>> I have the extension pgpro_scheduler. In the exception there are two
>> tables and the trigger on one of them that write to the other. I was
>> surprised but when I load dump created by pg_dump this trigger is
>> created in the pre-data stage (automatically by create extension) early
>> and thus has wrong behavior when uploaded data in the data stage (lead
>> to duplication of primary key).
>
> pg_dump does not like to editorialize on the contents of extensions.
> It just does CREATE EXTENSION and doesn't inquire into what's in
> them. I'd argue that if you need triggers like this, maybe you
> should rethink your data model.
>
> regards, tom lane
Okey, as I see
https://www.postgresql.org/docs/17/extend-extensions.html#EXTEND-EXTENSIONS-CONFIG-TABLES
Cite:
More complicated situations, such as initially-provided rows that
might be modified by users, can be handled by creating triggers on the
configuration table to ensure that modified rows are marked correctly.
So a trigger is permitted inside an extension. But usually trigger must
not be fired when pg_dump load data. May be it is hard for pg_dump to
reorder statements inside an extension. May be better just set
session_replication_role=replica by pg_dump and pg_restore? (To disable
triggers).
--
Olleg
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2025-02-21 07:01:02 | Re: May data be corrupted after an interrupted, but afterwards sucessfully replayed recovery? |
Previous Message | Jerry Sievers | 2025-02-21 03:57:43 | Re: In-place upgrade with streaming replicas |