> > > 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;
Hrm... if I changed the DBI layer for Ruby to have: db['AutoCommit'] = true use 'SET autocommit = ON; COMMIT;' I think I'd be breaking tons of applications where they wouldn't be expecting the commit. > 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. Yup, exceptions aren't elegant, but since there's only one way of SET'ting variables and this one is very key to transactions, I don't know of another way than possibly creating a parallel command to SET that'd avoid this rollback/commit silliness... but that seems like a step backwards and is why I'd think an exception would be good. -sc -- Sean Chittenden ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html