Re: serializable isolation level behavior question

>> 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.

> This must hold, no matter what any other transaction does, and
> irrespective
> of that other transaction's isolation level.
>

That's true for things like select, update or delete.

> 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.

> 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?

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

Which ones?

> Incidentally, it can be argued that Oracle handles the 'DROP TABLE' case
> correctly because you will get an error if you issue the same query again.
>
> I think the whole thing is nothing to get upset about, it's just yet
> another case where Oracle is not standard compliant.
>

I would love to see it if anyone can serialize TRUNCATE in any database. Received on Wed Oct 18 2006 - 19:10:30 CDT