Harpreet Dhaliwal wrote: > > > On 6/2/07, *Jasbinder Singh Bali* <jsbali@xxxxxxxxx > <mailto:jsbali@xxxxxxxxx>> wrote: > > > > On 6/2/07, *Michael Glaesemann* < grzm@xxxxxxxxxxxxxxx > <mailto:grzm@xxxxxxxxxxxxxxx>> 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.
