Re: Transactional DDL

Harpreet Dhaliwal wrote:
>
>
> On 6/2/07, *Jasbinder Singh Bali* <jsbali(at)gmail(dot)com
> <mailto:jsbali(at)gmail(dot)com>> wrote:
>
>
>
> On 6/2/07, *Michael Glaesemann* < grzm(at)seespotcode(dot)net
> <mailto:grzm(at)seespotcode(dot)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.