From: | "Michael Paesold" <mpaesold(at)gmx(dot)at> |
---|---|
To: | "Stephan Szabo" <sszabo(at)megazone(dot)bigpanda(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Foreign keys for non-default datatypes |
Date: | 2006-03-04 08:11:00 |
Message-ID: | 009d01c63f63$2d5400f0$0f01a8c0@zaphod |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>>> If we did this then RI checks would no longer be subvertible by rules
>>> or user triggers.
>
> Stephan Szabo writes:
>> I don't think that it'd really help because it's the actions that are
>> generally subvertible not the checks and since those are looking at the
>> potentially not indexed fk side, I don't think the above would apply.
>
> Oh, right, we'd probably still need to do planning in that case. Unless
> we wanted to insist on having an FK-side index too for every FK, which
> is something I'm not for.
I don't really understand the implications here, but I hope that the
following usecase will still work afterwards:
Two tables A, B.
B (id) references A (id), with ON DELETE CASCADE
Usually deleting a row from A will cause all referencing rows in B to be
deleted, too. Nevertheless B has a BEFORE DELETE trigger "check_delete" that
checks if a row of B may be deleted or not. I.e. it contains a IF ... RAISE
EXCEPTION...
Will this trigger still be called, so it can abort the delete?
If not, I am against that change because it will break the
consistency-enforcements of one of our applications.
In other words, if you only change the checks of the FKs, I see no problem
at all; but if you change the actions of FKs to not call user defined
triggers, I have a problem.
Please correct any of my wrong assumptions. ;-)
Best Regards,
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2006-03-04 09:11:11 | Re: pg_config --pgxs |
Previous Message | Magnus Hagander | 2006-03-04 08:09:05 | Re: Building Windows Server Extensions Using VC++ 2005 |