Re: Foreign keys for non-default datatypes - Mailing list pgsql-hackers

From Michael Paesold
Subject Re: Foreign keys for non-default datatypes
Date
Msg-id 009d01c63f63$2d5400f0$0f01a8c0@zaphod
Whole thread Raw
In response to Foreign keys for non-default datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Foreign keys for non-default datatypes
List 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 




pgsql-hackers by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: Building Windows Server Extensions Using VC++ 2005
Next
From: Thomas Hallgren
Date:
Subject: Re: pg_config --pgxs