Re: [HACKERS] Re: ALTER TABLE DROP COLUMN

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