Re: serializable isolation level behavior question

Bob Jones <email_at_me.not> wrote:
>>> Are we still talking about TRUNCATE? Serializing it is like serializing
>>> drop table. It does not make sense. I don't know what part was I not
>>> clear about.
>>
>> You have been very clear, but you are missing the point.
>>
>> A serializable transaction must not get different results when issuing the
>> same query twice. Period.
>>

>
> Again, truncate is not a query, it is not even a dml.

As has been pointed out, 'the query' I am talking about is the select statement that returns different results both times.

>> To be standard compliant, you must maintain serializability even if
>> somebody else does a DROP TABLE or TRUNCATE TABLE.
>> The fact that TRUNCATE is not part of the SQL standard has no implications
>> in this case!
>>

>
> Show me one database that can serialize truncate.

PostgreSQL.

>> Just because Oracle does not do it doesn't mean it cannot be done.
>> There are different approaches to a solution:
>> a) somehow pretend to the serializable transaction that the data are still
>> there.
>> b) throw an error.
>> c) use shared table locks that block DML statements.
>>

>
> Which one is standard compliant?

All of them. That's the point. It does not matter how you do it.

>> To include the usual flamebait, '(some) other database systems handle this
>> correctly'.
>>

>
> Which ones?

PostgreSQL.

> I would love to see it if anyone can serialize TRUNCATE in any database.

Check it out and enjoy.

Yours,
Laurenz Albe Received on Mon Oct 23 2006 - 03:44:43 CDT