From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove psql's -W option |
Date: | 2018-07-22 13:35:46 |
Message-ID: | alpine.DEB.2.21.1807220817580.24721@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> 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,
Looking at the protocol documentation, I cannot see why a fork would be
needed, because the password could be asked for when required at the
protocol level. If the client knew.
However, libpq does not seem to expose this logic, and/or it is not used
by "psql" which simply loops over "PQconnectdbParams", which seems to
reconnect from scratch each time (connectDBStart ends with
pqDropConnection).
Given the depth of function (PQconnectStartParams, connectDBStart,
PQconnectPool, pg_fe_sendauth, pg_password_sendauth), changing this
behavior without re-designing the whole connection functions and rewriting
the client logic, thus breaking compatibility, looks like a pain.
> 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.
Yep.
ISTM that the only way out would be to provide a callback function that
could be used to ask for the password, and that could be called probably
from pg_fe_sendauth (?) and implement the logic currently in psql main,
and probably other clients as well.
PQsetPasswordCallback(myfunction);
And nothing else would be changed at the client level.
However the compatibility is non trivial because of the link dependency.
Maybe there could be a define so that a client could be compatible with
older lib versions, eg:
#ifdef LIBPQ_HAS_SET_PASSWORD_CALLBACK
PQsetPasswordCallback(myfunction);
#endif
Possibly this is acceptable. Not sure.
Otherwise ISTM that "-W/--password" still has some minimal value thus does
not deserve to be thrown out that quickly.
--
Fabien
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-07-22 13:54:35 | Re: Negotiating the SCRAM channel binding type |
Previous Message | Alexander Korotkov | 2018-07-22 13:30:56 | Re: Reduce amount of WAL generated by CREATE INDEX for gist, gin and sp-gist |