Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Date: 2010-12-13 16:08:42
Message-ID: AANLkTinzJiq_2wzNXV3t+1dcOm+CTkUWjFqFXjfHPjRA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> (a) ALTER TABLE ... ADD FOREIGN KEY ... NOT VALIDATED INITIALLY;
> will add a FK but NOT run the check - we mark it as "check pending".
> Lock held: ShareRowExclusiveLock

Seems about right. Not sure whether the lock strength is correct.

> (b) Every new change to the table has the FK enforced - the triggers are
> fully enabled and active. (That could mean we update a row and have the
> update fail because of a FK violation.)

Also seems about right.

> 2. pg_validate_foreign_key('constraint name');
> Returns immediately if FK is valid
> Returns SETOF rows that violate the constraint, or if no rows are
> returned it updates constraint to show it is now valid.
> Lock held: AccessShareLock

I'm less sure about this part. I think there should be a DDL
statement to validate the foreign key. The "return the problem" rows
behavior could be done some other way, or just left to the user to
write their own query.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-13 16:12:47 Re: SQL/MED - file_fdw
Previous Message Dmitriy Igrishin 2010-12-13 16:07:31 Re: hstores in pl/python