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.

-Neil



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On 4/12/07, Neil Conway <neilc@samurai.com> 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.

--
marko

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Marko Kreen wrote:
> On 4/12/07, Neil Conway <neilc@samurai.com> 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 <bruce@momjian.us> 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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly