Re: [Re] Re: PREPARE and transactions

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