Re: Nested Transactions, Abort All

On Tue, 2004-07-06 at 10:25, Alvaro Herrera wrote:
> On Tue, Jul 06, 2004 at 08:15:14AM +0200, Dennis Bjorklund wrote:
> > On Mon, 5 Jul 2004, Alvaro Herrera wrote:
> >
> > > > begin/end because they are already in an explicit/implicit transaction
> > > > by default... How is the user/programmer to know when this is the case?
> > >
> > > I'm not sure I understand you. Of course you can issue begin/end. What
> > > you can't do is issue begin/end inside a function -- you always use
> > > subbegin/subcommit in that case.
> >
> > I've not understood why we need new tokens for this case. Maybe you've
> > explained it somewhere that I've missed. But surely the server know if you
> > are in a transaction or not, and can differentiate on the first BEGIN and
> > the next BEGIN.
>
> I think the best argument for this is that we need a command to abort
> the whole transaction tree, and another to commit the whole transaction
> tree. Those _have_ to be ROLLBACK (or ABORT) and COMMIT (or END),
> because the spec says they work like that and it would be hell for an
> interface like JDBC if they didn't. So it's out of the picture to use
> those commands to end a subtransaction.

Why not rollback all or commit all?

I really really don't like subbegin and subcommit. I get the feeling
they'll cause more problems we haven't foreseen yet, but I can't put my
finger on it. They just don't feel like "postgresql" to me. I'd rather
see extra syntax to handle exceptions, like rollback all or whatnot,
than subbegin et. al.

>
> Now, it's clear we need new commands to end a subtransaction. Do we
> also want a different command for begin? I think so, just to be
> consistent.

Sorry, but I respectfully disagree that it's clear.