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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
