Re: v3 protocol & string encoding - Mailing list pgsql-hackers

From Oliver Jowett
Subject Re: v3 protocol & string encoding
Date
Msg-id 40BA5EF3.7020702@opencloud.com
Whole thread Raw
In response to Re: v3 protocol & string encoding  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: v3 protocol & string encoding  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> writes:
> 
>>1) What encoding is used for strings sent and received during the 
>>startup phase?
> 
> 
> The startup packet itself will not get any encoding conversion AFAIR,
> so one way to look at it is that the data therein must be in server
> encoding.  In practice, there are no strings therein that really need
> conversion anyway.  (If you use characters outside 7-bit-ASCII for user
> or database names, you're going to have much worse problems than just
> this one.)

The encoding of user & database names was my main concern. If they can 
only be 7-bit ASCII in practice, that's easy..

>>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? I need to know the point in the stream to switch 
encodings. I suppose this is only an issue if there are pairs of 
encodings where "client_encoding" or the encoding names encode 
differently in the two encodings. Is it safe to assume that 7-bit ASCII 
is always encoded unchanged regardless of the encoding in use?

-O


pgsql-hackers by date:

Previous
From: Oliver Elphick
Date:
Subject: CVS tip problems
Next
From: Oliver Jowett
Date:
Subject: Re: Delaying the planning of unnamed statements until Bind