| 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: | Whole Thread | Raw Message | 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.
| 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 |