Re: Remove psql's -W option - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove psql's -W option
Date
Msg-id 27600.1532217817@sss.pgh.pa.us
Whole thread Raw
In response to Re: Remove psql's -W option  (Vik Fearing <vik.fearing@2ndquadrant.com>)
Responses Re: Remove psql's -W option  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Vik Fearing <vik.fearing@2ndquadrant.com> writes:
> On 22/07/18 00:41, Fabien COELHO wrote:
>> What is the rational?

> It's first on our list of things not to do:
> https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_psql_-W_or_--password

As I recall, when this has been discussed in the past, people objected
because they didn't like either (1) the extra server process fork and/or
network round trip caused when a password is needed, or (2) the server
log entry that gets generated about client disconnecting without supplying
a password.  (We don't log anything about it normally, but I'm not sure
that that's always true when using PAM, LDAP, connection poolers, etc.)
While those are surely niche concerns, it's not really apparent to me
what we gain by breaking them.

A possible positive reason for removing the option would be if we could
clean up this mess:
https://www.postgresql.org/message-id/E1egDgC-000302-FN@gemulon.postgresql.org
But no fair citing that argument without presenting an actual clean-up
patch, because it's not obvious how much cleaner we could make it.

BTW, all of our client programs have this switch, so if we did agree
to remove it, this patch doesn't go nearly far enough.

            regards, tom lane

PS: I found some interesting back-story here:
https://www.postgresql.org/message-id/flat/200712091148.54294.xzilla%40users.sourceforge.net


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Non-portable shell code in pg_upgrade tap tests
Next
From: Andrei Korigodski
Date:
Subject: pgbench: improve --help and --version parsing