Thread: Provide a way to not ask for a password in psql

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

Hi again,

Martin Pitt [2007-10-09 15:56 +0200]:
> (2) PGPASSFILE=/dev/null psql -l
>
>    With /dev/null I get a segfault (I'll probably send a patch for
>    that later).

Ah, it tried to free(pgpassfile) in PasswordFromFile(), but that is a
local stack variable.

Can you please apply this upstream?

Thanks,

Martin

--
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org
diff -Nur postgresql-8.3/build-tree/postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c
postgresql-8.3.new/build-tree/postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c
--- postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c    2007-07-23 19:52:06.000000000 +0200
+++ postgresql-8.3beta1/src/interfaces/libpq/fe-connect.c    2007-10-09 16:22:41.000000000 +0200
@@ -3723,7 +3723,6 @@
         fprintf(stderr,
         libpq_gettext("WARNING: password file \"%s\" is not a plain file\n"),
                 pgpassfile);
-        free(pgpassfile);
         return NULL;
     }

On Tue, Oct 09, 2007 at 04:32:02PM +0200, Martin Pitt wrote:
> Hi again,
>
> Martin Pitt [2007-10-09 15:56 +0200]:
> > (2) PGPASSFILE=/dev/null psql -l
> >
> >    With /dev/null I get a segfault (I'll probably send a patch for
> >    that later).
>
> Ah, it tried to free(pgpassfile) in PasswordFromFile(), but that is a
> local stack variable.
>
> Can you please apply this upstream?

Applied back to 8.1 which is where it appeared.

//Magnus

Martin Pitt wrote:

> For example, "psql -l" is a convenient
> method to check whether the postmaster is running at all,
> finished with startup and ready for connections.
>
Why not just "pg_ctl status"?


--
  Euler Taveira de Oliveira
  http://www.timbira.com/

Euler Taveira de Oliveira wrote:
> Martin Pitt wrote:
> > For example, "psql -l" is a convenient
> > method to check whether the postmaster is running at all,
> > finished with startup and ready for connections.
>
> Why not just "pg_ctl status"?

That doesn't check whether the server is actually answering requests.
And it cannot check remote hosts.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/