Hello,
first, congratulations for 8.3beta1. I built some initial
Debian/Ubuntu packages which went very smoothly.=20
I am now walking through the failures of my postgresql-common test
suite. One particular regression is that there seems to be no way any
more to inhibit the password prompt in psql. This is particularly bad
for noninteractive scripts. For example, "psql -l" is a convenient
method to check whether the postmaster is running at all,
finished with startup and ready for connections.
There is a command line switch -W which forces the password prompt,
but not an inverse switch to avoid it. So those three obvious
workarounds came to my mind:
(1) psql -l < /dev/null
Does not work because simple_prompt() reads from /dev/tty.
psql could check the already existing pset.notty and not enter the
do-while loop for asking for the password if it is True.
(2) PGPASSFILE=3D/dev/null psql -l
With /dev/null I get a segfault (I'll probably send a patch for
that later). With an empty dummy file it cannot find a matching
password and thus prompt me again. Admittedly this behaviour does
make sense, so it should not be altered.
(3) PGPASSWORD=3Dfoo psql -l
This trick with specifying an invalid password worked up until 8.2.
Unfortunately it stopped working now due to a slight code change:
if (PQstatus(pset.db) =3D=3D CONNECTION_BAD &&
- strcmp(PQerrorMessage(pset.db), PQnoPasswordSupplied) =3D=3D 0 &&
+ PQconnectionUsedPassword(pset.db) &&
=20=20=20
To get back the earlier behaviour, this could be reverted, or the
case could me made explicit with
- password =3D=3D NULL &&
+ password =3D=3D NULL && !getenv("PGPASSWORD") &&
My current workaround is to use the dodgy patch in (3), but I'd
prefer to use an official upstream sanctioned method.
Thank you!
Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org