Re: pg_restore with --disable-triggers discards ENABLE ALWAYS

From: Duncan Sands <duncan(dot)sands(at)deepbluecap(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: pg_restore with --disable-triggers discards ENABLE ALWAYS
Date: 2024-09-13 09:04:07
Message-ID: efe94b68-24f6-49c6-8283-8deb2f8b05d8@deepbluecap.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Tom, thanks for taking a look.

> The given recipe seems incomplete,

I'm not sure what is missing in the recipe. I just dropped and recreated the
database, and performed exactly the steps listed in my original email, and get
exactly the same result.

> 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.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Duncan Sands 2024-09-13 09:08:16 Re: pg_restore with --disable-triggers discards ENABLE ALWAYS
Previous Message Duncan Sands 2024-09-13 08:58:46 Re: pg_restore with --disable-triggers discards ENABLE ALWAYS