Sean Chittenden wrote:
> > Well there is discussion on whether a SET with autocommit off should
> > start a transaction if it is the first command. Right now it does, and
> > clearly you have a case where it acts strangely.
>
> Problem is that through various DB APIs such as DBI, you can't
> garuntee to the user doing development that that it's the 1st command
> that they're performing.
OK, but why does my suggestion not work:
SET autocommit = ON;
COMMIT;
> > This would not rollback the first SET because it wouldn't be part of
> > that transaction, causing all sorts of confusion.
> >
> > I assume the way to code your case is:
> >
> > > template1=# SET AUTOCOMMIT TO OFF;
> > > template1=# COMMIT;
> > > template1=# DROP DATABASE my_db_name;
> >
> > because in fact the SET doesn't become permanent until the COMMIT is
> > performed.
>
> I'm inclined to think that SET needs an exception for autocommit... I
> don't like exceptions, but I can't think of another SET that you'd do
> where you wouldn't want to roll it back. Eh? -sc
Yep, we don't like special cases and that is why we avoided it. Just
explaining the special case causes all sorts of confusion, as you have
seen from my emails.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
