Marko Kreen wrote: > On 4/12/07, Neil Conway <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-04-08 at 11:08 +0300, Marko Kreen wrote: > > > I think implicit ABORT would annoy various tools that > > > partially parse user sql and expect to know what transaction > > > state currently is. For them a new tranaction control statement > > > would be nuisance. > > > > That's not the only alternative: we could also either disallow all of > > the "ALL" variants in a transaction block, or allow RESET SESSION inside > > a transaction block. > > > > I've committed the patch basically as-is: thanks for the patch. I don't > > feel strongly about the above, but if there's a consensus, we can change > > the behavior later. > > Thanks for reviewing it. > > One argument for top-level ALL commands is also that > poolers and other tools in the middle of connection can track > them. But it could also argued that they should have similar > rules than ordinary CLOSE/DEALLOCATE statements. Also it seems > that disallowing them inside functions for no good reason is > couterproductive. > > But I also dont feel strongly either way.
I was thinking we would throw a WARNING rather than an error for RESET SESSION inside a transaction. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: 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