Re: disable and enable trigger all when a foreign keys

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: Emanuel Araújo <eacshm(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: disable and enable trigger all when a foreign keys
Date: 2019-07-12 14:43:13
Message-ID: 28189.1562942593@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2019-07-12 14:47:19 Re: Issue: Creating Symlink for data directory of postgresql in CentOS7
Previous Message Nicola Contu 2019-07-12 14:34:36 Re: Matview size - space increased on concurrently refresh