Skip site navigation (1) Skip section navigation (2)

AW: AW: [HACKERS] DROP TABLE inside a transaction block

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>
Cc: "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: AW: AW: [HACKERS] DROP TABLE inside a transaction block
Date: 2000-03-06 10:27:43
Message-ID: 219F68D65015D011A8E000006F8590C604AF7D0D@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: 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, and do
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

Next:From: Karel Zak - ZakkrDate: 2000-03-06 13:47:36
Subject: Re: ACL enhancements
Previous:From: Peter EisentrautDate: 2000-03-06 10:10:54
Subject: Re: [HACKERS] DROP TABLE inside a transaction block

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group