Re: String encoding during connection "handshake"

Ok, that's bad. I've also read crypt.c and md5.c.
And what a nightmare is C compared to Java (granted, there's a difference in
age of more than 20 years).

My guess is that since the "char" type is one byte long, all "char *"
expressions are actually pointers to array of bytes which are transmitted
through the wire and/or stored in the database. When these strings arrive
from or leave for a client that has another declared encoding than the
database, the string of bytes is replaced with an equivalent one from a
Unicode perspective. Am I right?

During the authentication phase, no such conversion takes place - you were
right and I couldn't believe it! In the case when your database name, your
user name or password contain non-ASCII characters, you're out of luck if the
stored values were submitted in another encoding by the administrator.

I assume that no names conversion takes place between client and cluster
metadata when a role is created (CREATE ROLE... PASSWORD...) or when a
database is created (CREATE DATABASE...). Or does it? In that case, the names
are encoded in the encoding of the database that the administrator was
connected to.

Thank you both.

On Tuesday 27 November 2007, Usama Munir wrote:
> Martin is actually right. No assumption is made about the encoding of the
> password. The password is recieved as a set of bytes over the wire-level
> protocol and then processed accordingly as per your pg_hba settings. please
> refer to auth.c method recv_password_packet(Port *port). The comment on the
> last line of the method might be of your intrest, and i quote
>
> "Return the received string, Note we do not attempt to do any character set
> conversion on it; since we don't know the client's encoding, there woudn't
> be much point"
>
> / Usama