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