Re: Transactional DDL

Harpreet Dhaliwal wrote:
>
>
> On 6/2/07, *Jasbinder Singh Bali* <jsbali@gmail.com
> <mailto:jsbali@gmail.com>> wrote:
>
>
>
>     On 6/2/07, *Michael Glaesemann* < grzm@seespotcode.net
>     <mailto:grzm@seespotcode.net>> wrote:
>
>
>         On Jun 2, 2007, at 11:08 , Harpreet Dhaliwal wrote:
>
>         > Whats so novel about postgresql here?
>         > This would happen in any RDBMS. right?
>         > You induced divide by zero exception that crashed the whole
>         > transaction and it did not create the table bar?
>
>         [Please don't top-post. It makes the discussion hard to follow.]
>
>         I used the divide by zero to raise an error to show that both the
>         CREATE TABLE and the INSERT were rolled back when the transaction
>         failed. If there's another definition of transactional DDL, I'd like
>         to know what it is.
>
>         Michael Glaesemann
>         grzm seespotcode net
>
>
>     This is what happens in every RDBMS.

No, it doesn't

>     Whats so special about postgres
>     then?
>
>
>
>
> Exactly. this seems like proving the ACIC property of a database thats
> true for every RDBMS.
> Whats so different in postgresql then?

Try doing the same test in MySQL (using InnoDB so you get a supposedly
ACID compliant table type).

Or even in Oracle.

You'll find that the table create gets committed *implicitly*, and the
rollback will only rollback the insert, not the table create.

The point is that most RDBMS systems treat DDL a little differently and
force transaction commit when they are executed. Postgres does not.