Re: Foreign key constaint can be broken

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Kazemier <mark(dot)kazemier(at)gmail(dot)com>, PostgreSQL Bugs List <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Foreign key constaint can be broken
Date: 2010-01-27 07:55:04
Message-ID: alpine.DEB.2.00.1001270848480.13155@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


>> I found a way to break a foreign key constraint in PostgreSQL
>> [ ie, make a rule that defeats an ON DELETE CASCADE operation ]
>
> This isn't a bug, it's just the way things work. Rules (and triggers)
> apply to the commands that implement foreign key updates, so a poorly
> written rule can make those queries do the wrong thing. The rule can
> make your regular queries do the wrong thing too, so it's not like you'd
> be fine if it were done some other way. There are a number of real
> applications that would be broken if rules/triggers *didn't* apply to
> FK queries --- for example, using a trigger to implement logging --- so
> we've concluded this is the most useful way for it to be done.

It may suggest that a rule may have a optionnal specifier to tell the
context in which it should be applied, for instance :

CREATE RULE ... ON [ ALL | INTERNAL | EXTERNAL ] UPDATE TO ...

Where "INTERNAL" would tag foreign key stuff while "EXTERNAL" would be
only the user stuff.

I'm not sure it would not add to the confusion, though.

--
Fabien.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Mike Bresnahan 2010-01-27 20:59:00 Amazon EC2 CPU Utilization
Previous Message Euler Taveira de Oliveira 2010-01-27 00:32:21 Re: Failed to run initdb - not resolved bug 5130