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?
I can't see any Transactional DDL philosophy here.
Could you please throw some more light on it to point out the transactional DDL fundamental as
pointed out by Jas?
Thanks,
~Harpreet
On 6/2/07, Michael Glaesemann <grzm@seespotcode.net> wrote:
On Jun 2, 2007, at 10:12 , Jasbinder Singh Bali wrote:
> But its said that transactions in any RDBMS follow ACID properties.
> So if i put a create table and an Insert statement in the same
> begin end block as one single transactioin, won't both create and
> insert follow acid property, being in one single trasaction, and
> either both get committed or none, talking about oracle lets say
test=# \d
List of relations
Schema | Name | Type | Owner
--------+------+-------+----------
public | a | table | postgres
public | b | table | postgres
(2 rows)
test=# begin;
BEGIN
test=# create table foo (a integer);
CREATE TABLE
test=# insert into foo (a) values (1);
INSERT 0 1
test=# commit;
COMMIT
test=# \d
List of relations
Schema | Name | Type | Owner
--------+------+-------+----------
public | a | table | postgres
public | b | table | postgres
public | foo | table | postgres
(3 rows)
test=# select * from foo;
a
---
1
(1 row)
test=# begin;
BEGIN
test=# create table bar (a integer);
CREATE TABLE
test=# insert into bar (a) values (1);
INSERT 0 1
test=# select * from bar;
a
---
1
(1 row)
test=# \d
List of relations
Schema | Name | Type | Owner
--------+------+-------+----------
public | a | table | postgres
public | b | table | postgres
public | bar | table | postgres
public | foo | table | postgres
(4 rows)
test=# select 1/0;
ERROR: division by zero
test=# commit;
ROLLBACK
test=# \d
List of relations
Schema | Name | Type | Owner
--------+------+-------+----------
public | a | table | postgres
public | b | table | postgres
public | foo | table | postgres
(3 rows)
Michael Glaesemann
grzm seespotcode net
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match