Re: Remove psql's -W option

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, 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-23 16:08:16
Message-ID: 17744.1532362096@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I also think your other question is a good one. It seems like the
> fact that we need to reconnect -- rather than just prompting for the
> password and then sending it when we get it -- is an artifact of how
> libpq is designed rather than an intrinsic limitation of the protocol.

Well, it's a limitation of the libpq API. The problem is that it's the
application, not libpq, that's in charge of actually asking the user for
a password. Right now we inform the app that it needs to do that by
passing back a failed PGconn with appropriate state. We could imagine
passing back a PGconn with a half-finished open connection, and asking
the app to re-submit that PGconn along with a password so we could
continue the auth handshake. But it'd require changing apps to do that.

Also, doing things like that would incur the risk of exceeding
authentication_timeout while the user is typing his password. So we'd
also need some additional complexity to retry in that situation.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-07-23 16:11:13 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Alvaro Herrera 2018-07-23 16:03:32 Re: cached plans and enable_partition_pruning