My 0.02€:

Patch applies cleanly, make check ok... however AFAICS it only means that it compiles but it is not tested in anyway... This is is annoying. Well I'm not sure whether other options are tested either, but they should.

ISTM that this feature is already available through the PGPASSFILE environment variable, so this is really just about providing the same feature through a connection string option, if I'm not mistaken. I'm fine with that.

The documentation needs to be updated.

I'm not much concerned about security issues as discussed on the thread. If an attacker can control the file, then what... they can provide a password in my place in a file of their own? If they have the pass then it works, if they do not then the connection will fail... They cannot change the database I'm connecting to from the pass file, say to provide other credentials to an application. So I do not see this as worst that the current status.

I tested the feature through python/psychopg2 by setting LD_LIBRARY_PATH to the dev version. I got a strange behavior wrt to errors. With "./foo" containing the right password it is fine.

  import psycopg2 as pg
  c = pg.connect("host=localhost dbname=test user=test pgpassfile=./foo")
  # ok

Now if "./foo" contains a bad password:

  import psycopg2 as pg
  c = pg.connect("host=localhost dbname=test user=test pgpassfile=./foo")
  # error:
  OperationalError: FATAL:  password authentication failed for user "test"
  password retrieved from file "$HOME/.pgpass"

The reported password file is wrong. It is even more funny if ~/.pgpass contains the right password: the pgpassfile option *is* taken into account, ./foo is read and it fails, but the error message is not updated and points to the wrong file. The error message stuff should be updated to look for the pgpassfile connection string option...

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to