From: Duncan Sands <duncan.sands@deepbluecap.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
To: pgsql-bugs@lists.postgresql.org
Subject: Re: pg_restore with --disable-triggers discards ENABLE ALWAYS
Date: Fri, 13 Sep 2024 10:58:46 +0200
Message-ID: <dd4e17f5-0c42-49ac-92e9-2db648bb55b9@deepbluecap.com> (raw)
In-Reply-To: <78a13f951a03bf325027f8dcfb32b1b5089cdb14.camel@cybertec.at>
References: <d374b6fc-4217-48a9-8639-2c9b4d3a92d0@deepbluecap.com>
<78a13f951a03bf325027f8dcfb32b1b5089cdb14.camel@cybertec.at>
Hi Laurenz,
On 12/09/2024 22:02, Laurenz Albe wrote:
> On Thu, 2024-09-12 at 10:27 +0200, Duncan Sands wrote:
>> CREATE TABLE test_table(x int);
>> CREATE FUNCTION test_function() RETURNS trigger AS $$ BEGIN RETURN NULL; END; $$
>> LANGUAGE plpgsql;
>> CREATE TRIGGER test_trigger AFTER UPDATE ON test_table FOR EACH ROW EXECUTE
>> FUNCTION test_function();
>> ALTER TABLE test_table ENABLE ALWAYS TRIGGER test_trigger;
>>
>> Checking the table:
>>
>> duncan=> \d test_table
>> Table "public.test_table"
>> Column | Type | Collation | Nullable | Default
>> --------+---------+-----------+----------+---------
>> x | integer | | |
>> Triggers firing always:
>> test_trigger AFTER UPDATE ON test_table FOR EACH ROW EXECUTE FUNCTION
>> test_function()
>>
>> ^ Observe "Triggers firing always".
>>
>>
>> Now for the dump + restore:
>>
>> pg_dump -f dump.custom -Fc --table test_table
>> pg_restore --data-only --disable-triggers --dbname duncan dump.custom
>>
>> Checking the table:
>>
>> duncan=> \d test_table
>> Table "public.test_table"
>> Column | Type | Collation | Nullable | Default
>> --------+---------+-----------+----------+---------
>> x | integer | | |
>> Triggers:
>> test_trigger AFTER UPDATE ON test_table FOR EACH ROW EXECUTE FUNCTION
>> test_function()
>>
>> ^ 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.
No, the trigger was ENABLE ALWAYS when dumped, and restoring zapped that. To
confirm that it was ENABLE ALWAYS when dumped:
$ pg_restore -f - dump.custom | grep 'ENABLE ALWAYS'
ALTER TABLE public.test_table ENABLE ALWAYS TRIGGER test_trigger;
To summarize: the table existed before the restore, and the trigger was ENABLE
ALWAYS at the moment it was dumped as shown in the steps to reproduce above: I
create the table, make an ENABLE ALWAYS trigger, then dump the table, then
restore the dump with --data-only and --disable-triggers. At which point (in
spite of --data-only) the table has been modified: the trigger is no longer an
ENABLE ALWAYS trigger.
Best wishes, Duncan.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: duncan.sands@deepbluecap.com, laurenz.albe@cybertec.at, pgsql-bugs@lists.postgresql.org
Subject: Re: pg_restore with --disable-triggers discards ENABLE ALWAYS
In-Reply-To: <dd4e17f5-0c42-49ac-92e9-2db648bb55b9@deepbluecap.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox