On Mon, Jul 05, 2004 at 10:21:26AM +1200, Oliver Jowett wrote: > It certainly affects the JDBC driver -- the native String representation > in Java is UTF-16, so the driver transcodes between that and > client_encoding for parameterized queries and query results involving > strings. Oops, yeah, I forgot. 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 > So at least from that point of view, client_encoding is very much a > protocol-level thing. Much as I see PREPARE :) The Interchange layer is the ugly stepchild here; it's controlled at the SQL level but should be handled either by the application or in middleware, together with the Protocol layer. The model really seems to assume that it belongs in the application, which in your case of course is not an option. If they were placed at the driver level (together with Protocol) then I'd see how they might as well be nontransactional. Are there even significant uses of session variables other than controlling the Interchange layer? 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. Jeroen ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster