Jan Wieck wrote:
>
> Explanative version of "that other story". But not exactly
> correct IMHO. If following strictly SQL3 suggestions, an ON
> DELETE RESTRICT action cannot be deferrable at all. Even if
> the constraint itself is deferrable and is set explicitly to
> DEFERRED, the check should be done immediately at ROW level.
> That's the difference between "NO ACTION" and "RESTRICT".
>
> Actually, a RESTRICT violation can potentially bypass
> thousands of subsequent queries until COMMIT. Meaningless
> from the transactional PoV, but from the application
> programmers one (looking at the return code of a particular
> statement) it isn't!
...
> It'll be expensive, compared to current UNIQUE implementation
> doing it on the fly during btree insert (doesn't it?). But
> the only way I see.
So currently we have ON UPDATE RESTRICT foreign keys :)
-------------
Hannu