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.