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 :)
In response to
pgsql-hackers by date
|Next:||From: Jan Wieck||Date: 2000-02-29 10:22:27|
|Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN|
|Previous:||From: Jose Soares||Date: 2000-02-29 08:34:59|
|Subject: Re: [HACKERS] having and union in v7beta|