AW: AW: [HACKERS] DROP TABLE inside a transaction block - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: AW: [HACKERS] DROP TABLE inside a transaction block
Date
Msg-id 219F68D65015D011A8E000006F8590C604AF7D0D@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List pgsql-hackers
> > Yes, that was also the general consensus on the list. No statement is
> > ever going to do an implicit commit of previous statements.
> 
> I can understand that, but one of these days I hope we can offer the SQL
> semantics of transactions where you don't require a BEGIN. 
> (*Optional*,people.) In that case you have to do *something* about 
> non-rollbackable DDL (face it, there's always going to be one). Doing what

> Oracle does is certainly not the *worst* one could do. Again, optional.

Imho it *is* the worst one can do.
The only also bad, but acceptable solutions to me would be:

1. disallow this DDL if there is any open DML in this tx,( allow it, if only select or DDL statements since tx open,
anddo
 
the implicit commit)
2. handle this DDL outside any transaction scope even if a tx is open

Implicitly committing previous DML with a DDL statement is imho out of
discussion.

Not in the scope of this discussion is imho the "truncate" command,
since it is 1. not SQL92, 2. per definition a non rollbackable statement
and 3. probably rather a DML statement.

> That still doesn't excuse the current behavior though.

Agreed

Andreas


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Next
From: Mike Mascari
Date:
Subject: Re: AW: [HACKERS] DROP TABLE inside a transaction block