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: (view raw, whole thread or download thread mbox)
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

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.



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-2017 The PostgreSQL Global Development Group