Skip site navigation (1) Skip section navigation (2)

Re: v3 protocol & string encoding

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: v3 protocol & string encoding
Date: 2004-05-31 05:10:16
Message-ID: 40BABE38.9010906@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-05-31 06:31:14
Subject: Re: CVS tip problems
Previous:From: Tom LaneDate: 2004-05-31 04:04:21
Subject: Re: v3 protocol & string encoding

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group