Skip site navigation (1) Skip section navigation (2)

String encoding during connection "handshake"

From: sulfinu(at)gmail(dot)com
To: pgsql-hackers(at)postgresql(dot)org
Subject: String encoding during connection "handshake"
Date: 2007-11-27 12:51:32
Message-ID: 200711271451.32145.sulfinu@gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi all.

I have read the documentation, searched the mailing lists and inspected the 
code JDBC driver code. I do need to address this question to actual 
developers.

Simply put, what is the client encoding that the server assumes BEFORE the 
client connection is established, that is, during the authentication phase? I 
know there's a "client_encoding" setting on the server side that indicates 
the encoding used in the communication stream, but its default value is the  
database's encoding. Which is not known before the user gets authenticated 
and the "logical" connection is actually made.

I'm asking this so that I can fix the JDBC driver that wrongly assumes that 
user name, password and database name are made up of ASCII characters only. 
This issue has come up before, but no action has been carried out. See 
http://archives.postgresql.org/pgsql-jdbc/2007-10/msg00128.php
I also need a vital information regarding the MD5 hash that is computed is 
some authentication scenarios. This hash is based on char[] (String) values 
that must be converted into byte[] before being handed over to the hash 
algorithm. What is the encoding used by the server to make this conversion 
during the authentication phase (in order to verify the submitted password)?

I also saw that the JDBC driver sends right away this pair to the server: 
{"client_encoding", "UNICODE"}. Does that mean that the client is requesting 
the server to interpret the communication stream as encoded in "UTF8"?

Thanks.

Responses

pgsql-hackers by date

Next:From: Hubert FONGARNANDDate: 2007-11-27 13:41:07
Subject: PostGreSQL and recursive queries...
Previous:From: Simon RiggsDate: 2007-11-27 12:03:38
Subject: Re: Replacement Selection

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group