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

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.

Yours,
Laurenz Albe