On Mon, Jul 05, 2004 at 11:44:08PM +1200, Oliver Jowett wrote:
> > SQL session - temp tables, session variables, database contents
> > Interchange - encoding & representation
> > Protocol - COPY, bind/execute &c.
> > Connection - socket stuff
> >Transactions come into play at the Protocol level, and the way things are
> >implemented, go all the way up to SQL level. Only the Connection level is
> >entirely nontransactional, and the SQL layer to my intuition ought to be
> >exclusively transactional. The only current exception to that that springs
> >to mind is the way PREPARE is implemented.
>
> Other exceptions I can think of are FETCH and DEALLOCATE. DEALLOCATE is
Well, I'd say DEALLOCATE is implicitly lumped in with PREPARE. But as for
FETCH, are you referring to cursors that live outside transactions (but get
manipulated inside transactions)? Are those implemented yet and if so, how
does FETCH work there? There's just been a discussion here about how
nested transactions should not be allowed to FETCH from cursors defined in
a wider scope for precisely this reason: to ensure neat transactional
behaviour.
> particularly fun -- don't most of the arguments for making PREPARE
> transactional also apply to DEALLOCATE? Is it actually feasible to roll
> back a DEALLOCATE?
I can see how it gets a bit more complicated when you DEALLOCATE, then
PREPARE a new statement with the same name in the same transaction. But
nothing that a transaction-local mapping (plus "being deleted" bit) can't
fix, AFAICS.
Jeroen
