Peter Eisentraut <peter_e@gmx.net> writes:
> The silent assumption behind the client_encoding parameter is that you
> must set it to the actual character set encoding used by the client. If
> you lie, the results are unspecified. So if you're in a JDBC application
> and set the client encoding to an encoding that the JDBC driver (that is,
> "the client") cannot handle, you lied and you deserve to lose.
I think the issue is not so much whether the JDBC driver *can* handle
the encoding, as whether it knows what it needs to be doing right now.
> There are real and valid reasons for changing the client encoding on the
> fly, but that is no reason to make a big deal about passing the
> information around all the time.
If the JDBC driver needs to do anything different for one encoding than
another, then it needs to be informed of changes. We can debate what's
the most appropriate way to keep it informed, but I don't think we can
just ignore the need to inform it.
regards, tom lane