Re: pg_restore with --disable-triggers discards ENABLE ALWAYS - Mailing list pgsql-bugs

From Tom Lane
Subject Re: pg_restore with --disable-triggers discards ENABLE ALWAYS
Date
Msg-id 4156698.1726174027@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_restore with --disable-triggers discards ENABLE ALWAYS  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: pg_restore with --disable-triggers discards ENABLE ALWAYS
Re: pg_restore with --disable-triggers discards ENABLE ALWAYS
List pgsql-bugs
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Thu, 2024-09-12 at 10:27 +0200, Duncan Sands wrote:
>> pg_restore --data-only --disable-triggers --dbname duncan dump.custom
>> ^ Observe that "Triggers firing always" has disappeared.

> This looks like a user error to me.
> If you restore with --data-only, the table and constraint definitions
> are not restored at all.  So the table "test_table" in database "duncan"
> must already have existed before the restore, and the trigger was already
> defined like that.

The given recipe seems incomplete, but I think Duncan has put his
finger on a shortcoming.  pg_restore with --disable-triggers will
issue

ALTER TABLE foo DISABLE TRIGGER ALL;

and later

ALTER TABLE foo ENABLE TRIGGER ALL;

and if you read the fine print in the ALTER TABLE man page,
you'll discover that ENABLE TRIGGER sets the triggers' replication
mode to the default (origin only).  I'm not sure why somebody
thought that replication mode shouldn't be stored separately
from enable/disable, but it isn't: there's just one four-valued
state field.

We could probably add code to make pg_dump individually re-enable
the table's triggers with the appropriate state(s), but I can't
muster too much enthusiasm for writing that myself.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: pg_restore with --disable-triggers discards ENABLE ALWAYS
Next
From: Thomas Munro
Date:
Subject: Re: BUG #18610: llvm error: __aarch64_swp4_acq_rel which could not be resolved