> > 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 - Zakkr||Date: 2000-03-06 13:47:36|
|Subject: Re: ACL enhancements|
|Previous:||From: Peter Eisentraut||Date: 2000-03-06 10:10:54|
|Subject: Re: [HACKERS] DROP TABLE inside a transaction block|