Sayan,
Not really, because ACID is at the transaction level, and here we are
talking of what happens at the statement level. Kind of sub-atomic :-).
I agree that this kind of behaviour is rather disturbing. Especially in
Franck's example, what is shocking is that it works in one case and not
in the other one. Of course it's perfectly understandable when you
consider that PostgreSQL takes rows in sequence - but order has no
particular meaning in SQL. Potentially, a change in the optimizer, even
a data reload, could make fail an update that used to work simply
because row updates are no longer performed in the same order. I would
have liked to see consistency throughout - failure in both cases, or
success in both cases.
It would make more sense for me if all constraints were created deferred
by default - which cannot be done with a PK. Now, Franck's example is a
bit unfortunate as it uses a primary key. Updating a primary key? I
hope he will reread Chris Date's complete works as a penance.
SF
On 24/07/2017 16:55, Sayan Malakshinov wrote:
Stéphane,
This behavior breaks A from ACID...
Best regards,
Sayan Malakshinov
http://orasql.org
