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

Re: String encoding during connection "handshake"

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: sulfinu(at)gmail(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: String encoding during connection "handshake"
Date: 2007-11-27 14:58:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Nov 27, 2007 at 02:51:32PM +0200, sulfinu(at)gmail(dot)com wrote:
> 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 was under the impression that the username/password, had no encoding,
they are Just a Bunch of Bits, i.e. byte[]. Hence it is not relevent
what encoding the database is, it depends what encoding the DB admin
was using when the user was created. That solves your md5 problem.

Looking at it another way, the encoding is part of the password. The
correctly entered password in the wrong encoding is also wrong, because
the matching is done at the byte level.

So I suppose the answer is: whatever encoding you would like it to
be/what the DB admin uses.

This is all AIUI,

Have a nice day,
Martijn van Oosterhout   <kleptog(at)svana(dot)org>
> Those who make peaceful revolution impossible will make violent revolution inevitable.
>  -- John F Kennedy

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-11-27 15:00:35
Subject: Re: PostGreSQL and recursive queries...
Previous:From: Greg Sabino MullaneDate: 2007-11-27 14:55:50
Subject: Re: Proposed patch for operator lookup caching

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