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

From: Rob Wultsch <wultsch(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Date: 2010-12-13 05:59:39
Message-ID: AANLkTinbciF26yrA-a_vV-fKbqf8=89fTytAfYHsHyCc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 12, 2010 at 7:24 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> In fact it's possible now to disable FK enforcement, by disabling the
> triggers. It's definitely a footgun though. Just the other day I was asked
> how data violating the constraint could have got into the table, and caused
> some surprise by demonstrating how easy this was to produce.

Ugh. I have read the entire pg manual and I did not recall that
footgun. At least in MySQL disabling fk's is explicit. There is
something to be said for being able to tell the database: "Hey, hold
my beer and watch this, it might be stupid but it is what we are going
to do". The database telling it's user that is a much larger issue
(and yes, MySQL is generally worse). The user at least gets to talk to
db through sql, the database only really gets to talk to the user
through errors and the manual.

The fact that fk checks are implemented by the trigger system somehow
seems "surprising".

--
Rob Wultsch
wultsch(at)gmail(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rob Wultsch 2010-12-13 06:15:34 Re: unlogged tables
Previous Message Glen Knowles 2010-12-13 05:54:21 Re: [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags