Jeroen T. Vermeulen wrote:
> So perhaps we should be distinguishing several
> layers in a session's state, along the lines of:
>
> SQL session - temp tables, session variables, database contents
> Interchange - encoding & representation
> Protocol - COPY, bind/execute &c.
> Connection - socket stuff
That's not a bad model -- now we get to argue about what goes where ;)
> 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
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?
-O
