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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(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 18:49:30
Message-ID: 1292266170.2737.3184.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2010-12-13 at 17:15 +0000, Peter Geoghegan wrote:
> On 13 December 2010 16:08, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >> 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.
>
> +1. I think that a DDL statement is more appropriate, because it makes
> the process sort of symmetrical.

OK, sold.

> Perhaps we could error on the first FK violation found, and give a
> "value 'foo' not present in table bar". It ought to not matter that
> there could be a lot of violations, because they will be exceptional
> if you're using the feature as intended - presumably, you're going to
> want to comb through the data to find out exactly what has gone wrong
> for each violation. On the off chance that it actually is a problem,
> the user can go ahead and write their own query, like Robert
> suggested.

I think a function would help here, so I'll do that also.

--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2010-12-13 18:53:56 Re: proposal : cross-column stats
Previous Message Heikki Linnakangas 2010-12-13 18:34:43 Re: GiST insert algorithm rewrite