From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: v3 protocol & string encoding |
Date: | 2004-05-31 04:04:21 |
Message-ID: | 6609.1085976261@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> The encoding of user & database names was my main concern. If they can
> only be 7-bit ASCII in practice, that's easy..
Well, you can *try* using other encodings, but there are enough known
problems that I don't think it will work pleasantly unless client and
server encodings are the same all the time.
>>> 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?
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2004-05-31 05:10:16 | Re: v3 protocol & string encoding |
Previous Message | Oleg Bartunov | 2004-05-31 02:48:40 | Re: yet another contrib module |