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 contentsInterchange - encoding & representationProtocol - 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