Adam wrote:

>>... So, unless you're extremely lucky
>>and update the rows in descending order, one of the intermediate
>>results will violate the constraint and the whole update will
>>fail.
>
> It would work if there was only one record ;)

And that's why I wrote "probably" and "unless you're
extremely lucky"...

>
> I never encounter this problem because none of my primary keys have
> any real world significance. They are values dished out by a
> generator. There is no need to ever update them.

Which is good, but reduces the utility of cascade in foreign
key constraints.

>
> Sadly, deferred constraints is a low priority for now (Roadmap 06),
> but a good eye for picking up on that.

Deferred constraints are a different issue - and a feature of
the SQL Standard that we don't support. The question of verb
time versus row change evaluation of constraints is a bug and
is of higher priority I think. Deferred constraints are
evaluated at the end of the transaction so they can handle
questions like keeping accounts in different tables balanced.


Regards


Ann