Re: oracle-l Digest V14 #190

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

--
http://www.freelists.org/webpage/oracle-l