Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> writes:>
>>>>2) At what point in the stream does a client_encoding change take effect
>>>>-- immediately after the corresponding ParameterStatus message, or at
>>>>some other point?
>>>
>>>ParameterStatus is sent when the change is made.
>
>>Are the strings in the ParameterStatus encoded with the old or new
>>client_encoding?
>
> Okay, make that "sent just after the change is made". So it looks like
> you should receive a string in the new encoding. I can't offhand think
> of a way to test this though --- are any of the reported settings
> interesting from an encoding standpoint?
This timing makes it harder for a client to recognize a change in
client_encoding -- how is it supposed to know to change encoding before
interpreting the ParameterStatus message?
I'd like to add some robustness to the JDBC driver such that if the user
changes client_encoding, the driver throws an error rather than garbling
data (it is expecting client_encoding = 'UNICODE'). If the user can set
client_encoding such that the driver won't recognize the ParameterStatus
message (i.e. the string "client_encoding" does not encode as it would
in UNICODE), it's not so useful. I don't know if there is such an
encoding, however.
>>Is it safe to assume that 7-bit ASCII
>>is always encoded unchanged regardless of the encoding in use?
>
>
> Hm. This is true for all the "backend-safe" encodings but I believe
> not for all the supported client encodings. Tatsuo might have more of
> a clue than me about likely failure cases.
By "backend-safe" do you mean "can be used as a database encoding"?
If so, it solves my problem, which is handling the switchover from
default client_encoding (== database encoding) to UNICODE in the JDBC
driver's connection setup code. I can initially use 7-bit ASCII
regardless of the actual database encoding, and switch to UNICODE when
possible (this is what the current driver does in most cases, I'm just
verifying that the assumptions it makes are correct).
-O
