Re: disable and enable trigger all when a foreign keys - Mailing list pgsql-general

From Tom Lane
Subject Re: disable and enable trigger all when a foreign keys
Date
Msg-id 28189.1562942593@sss.pgh.pa.us
Whole thread Raw
In response to Re: disable and enable trigger all when a foreign keys  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: disable and enable trigger all when a foreign keys  (Emanuel Araújo <eacshm@gmail.com>)
Re: disable and enable trigger all when a foreign keys  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-general
Adrian Klaver <adrian.klaver@aklaver.com> writes:
> On 7/12/19 7:04 AM, Tom Lane wrote:
>> Well, yeah, DISABLE TRIGGER ALL defeats enforcement of FK constraints.
>> That's why you have to be superuser to use it[1].

> The OP is probably trying to understand why the below happens:

> alter table a add constraint a_id_b_fkey foreign key (id_b) references 
> b(id);
> ERROR:  insert or update on table "a" violates foreign key constraint 
> "a_id_b_fkey"
> DETAIL:  Key (id_b)=(3) is not present in table "b".

> Versus the above not happening when you re-enable a trigger.

Well, because ALTER ... ENABLE TRIGGER does what it says on the tin: it
re-enables firing of the trigger.  That means future inserts and updates
will be checked; it doesn't extend to somehow checking events for which
trigger firings didn't happen in the past.

The OP already found the best method to get out of this, which is to
drop and re-add the FK constraint.  Adding the constraint will force
a full verification scan, which is what you need here since there's
no information available about which checks were missed.

            regards, tom lane



pgsql-general by date:

Previous
From: Nicola Contu
Date:
Subject: Re: Matview size - space increased on concurrently refresh
Next
From: Laurenz Albe
Date:
Subject: Re: Issue: Creating Symlink for data directory of postgresql inCentOS7