Re: [HACKERS] DROP TABLE inside a transaction block

At 07:59 6/03/00 +0100, Peter Eisentraut wrote:
>> (such as TRUNCATE) make no sense with respect to ROLLBACK. So, I
>> guess, the idea is that SOME DDL statements will be ROLLBACK-able
>> and some won't - yuck.
>
>I don't see a problem with disallowing some DDL commands in a transaction
>as long as they throw an error and the transaction aborts.

Is it really necessary to abort the TX? Seems a little antisocial - can't
you just return an error, and let the user/application decide if it needs
to abort?

>> 3) Implicitly commit the running transaction and begin a new one.
>> Only Vadim and I support this notion, although this is precisely
>> what Oracle does (not that that should define PostgreSQL's
>> behavior, of course). Everyone else, it seems wants to try to
>> implement #1 successfully...(I don't see it happening any time
>> soon).
>
>I support that too since it also happens to be SQL's idea more or less.
>One of these days we'll have to offer this as an option. At least for
>commands for which #1 doesn't work yet.

Do you really mean it when ou say 'Implicitly commit the running
transaction'. I would be deeply opposed to this philosophically, if so. No
TX should ever be commited unless the user requests it.

Just my 0.02c

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/