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-30 15:32:26 |
Message-ID: | 15424.1085931146@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:
> 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.)
Any client_encoding received from the client is not going to be applied
until after the authentication exchange is complete, so the rest of that
is going to be in server encoding as well. The only part of this that
seems like it might be an issue is a failure ERROR message would be in
server encoding, but the client wouldn't have any good way to know what
that is ...
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-05-30 16:03:58 | Re: Converting postgresql.conf parameters to kilobytes |
Previous Message | Bruce Momjian | 2004-05-30 14:07:37 | Re: CVS tip compiler error with --enable-thread-safety |