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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate