From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Mujjamil k <mujjamil995@gmail.com>,
        Laurenz Albe <laurenz.albe@cybertec.at>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18516: Foreign key data integrity is not validated when
 reenabled the trigger on tables
In-reply-to: <202406201307.ojevjmezqu45@alvherre.pgsql>
References: <202406201307.ojevjmezqu45@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Thu, 20 Jun 2024 15:07:44 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <354612.1718898657.1@sss.pgh.pa.us>
Date: Thu, 20 Jun 2024 11:50:57 -0400
Message-ID: <354613.1718898657@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/354613.1718898657%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I think it's not a bad idea to suggest that we could have a new command
> ALTER TABLE .. DISABLE CONSTRAINT, which can be run by the table owner
> and paired with a later ALTER TABLE ENABLE CONSTRAINT, which verifies
> the constraint.

The existing, supported way to do this is to drop the foreign key
constraint and then later re-create it.

As noted, if you mess with the triggers directly then any subsequent
breakage is your responsibility.

			regards, tom lane