Re: Foreign keys for non-default datatypes

Tom Lane writes:

> "Michael Paesold" <mpaesold(at)gmx(dot)at> writes:
>> Will this trigger still be called, so it can abort the delete?
>
> We'd certainly still call triggers and check row-level constraints,
> and any error would abort the whole statement (leaving A unmodified).
>
> The case that I think we'd forbid if the implementation could support
> doing so is where a BEFORE trigger cancels the B-update operation by
> returning NULL. This currently leaves you with a row in B that violates
> the FK constraint (once the A row is gone).
>
> Triggers that modify the row to be stored are not a problem, because
> B will have an AFTER trigger that rechecks the row against A anyway.
> AFAICS it's only the silent-cancellation case that subverts RI
> constraints.
>
> Rules on B that rewrite the DELETE or UPDATE into something else are
> also problematic.
>
> This is all moot at the moment since Stephan pointed out that we still
> need planning for the FK actions (ie the cascaded deletes/updates).
> So I'm not currently thinking of redoing the implementation of actions.

Ok, thank you for the explanation. At least I am not worried about a future
reimplementation of the RI triggers.

Best Regards,
Michael Paesold