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

Re: JDBC driver patch for non-ASCII users

From: sulfinu(at)gmail(dot)com
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: JDBC driver patch for non-ASCII users
Date: 2007-12-11 15:22:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
On Tuesday 11 December 2007, Oliver Jowett wrote:
> A general String certainly might contain non-ASCII, but all Strings
> returned by UnixCrypt.crypt() contain only ASCII. See the implementation
> of UnixCrypt.crypt(), and in particular the UnixCrypt.cov_2char array.
> So I still do not understand why the change quoted above is necessary.
> Can you explain why it is necessary?
As I already stated, UnixCrypt looks like a lost cause to me. It truncates a 
lot of the information in the password (try to imagine what happens to a 
Unicode password at line 620), so it's result is a little more relevant than 

> The server only ever sends a subset of ASCII as crypt salt characters
> (specifically, the 62 characters a-z A-Z 0-9), so US-ASCII is just fine
> for decoding. See postmaster.c, RandomSalt() / RemapChar().
I didn't know that, I'll take your word for it. Is it officially specified 
anywhere? Can it be relied upon in the future?

I used the same Encoding.AUTHENTICATION_PHASE_ENCODING in all places for 
consistency and it doesn't harm in any way, since I make sure it is an ASCII 

In response to


pgsql-jdbc by date

Next:From: Oliver JowettDate: 2007-12-11 22:32:00
Subject: Re: JDBC driver patch for non-ASCII users
Previous:From: sulfinuDate: 2007-12-11 14:46:13
Subject: Re: JDBC driver patch for non-ASCII users

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