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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org