On Sat, Jan 28, 2012 at 7:47 PM, Euler Taveira de Oliveira
> On 28-01-2012 18:55, Andy Grimm wrote:
>> It's not uniform between the client and the server, though.
> The server doesn't impose a hard limit for password length and AFAICS it
> should not because we aim for backward compatibility.
>> It sounds like you are suggesting
>> that rather than increase the limit in the simple_prompt calls, you'd
>> prefer to decrease the limit read from pwfile? That doesn't
>> particularly help me.
> No, I am not. So there are three concerns here: (i) increase the limit for
> simple_prompt() and (ii) raise an error when we reach that limit and (iii) fix
> the PasswordFromFile(). Looking at your patch, it seems to fix only (i).
Sorry that it's been a couple of weeks, but I have gotten around to
working on a patch that address more of these concerns. The attached
1) allow arbitrary length passwords to be read from a file via initdb --pwfile
2) allow the client to accept a password of arbitrary length at the
3) allow a password of arbitrary length in a pgpass file
In #2 I say "allow the client to accept", because there's a
pq_getmessage call in src/backend/libpq/auth.c which limits the
password message length to 1000 characters. Changing that part of the
code should allow longer passwords, but there may be other lurking
backend issues after that, and I'm not concerned about going beyond
1000 at this point.
>> require understanding of what the real password length limit in a
>> database is.
> There is no such limit; it is stored in a text datatype.
> Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
> PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
In response to
pgsql-bugs by date
|Next:||From: Duncan Rance||Date: 2012-02-15 09:18:56|
|Subject: Re: BUG #6457: Regexp not processing word (with special characters on ends) correctly (UTF-8) |
|Previous:||From: Tom Lane||Date: 2012-02-14 23:45:29|
|Subject: Re: BUG #6459: logging_collector=off but log_filename set inhibits logoutpu |