Re: v3 protocol & string encoding
От | Tom Lane |
---|---|
Тема | Re: v3 protocol & string encoding |
Дата | |
Msg-id | 6609.1085976261@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: v3 protocol & string encoding (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: v3 protocol & string encoding
|
Список | pgsql-hackers |
Oliver Jowett <oliver@opencloud.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
В списке pgsql-hackers по дате отправления: