Fix recently-introduced breakage in psql's \connect command.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 29 Nov 2020 20:22:04 +0000 (15:22 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 29 Nov 2020 20:22:04 +0000 (15:22 -0500)
commite2d5de15003d17e2f5c91a5c9151528031a97014
treeaedc7ac194cbbfe671ebbc0738840682da6c6502
parent414fb255e55f249f2c5e6d207ef6bd98c460a730
Fix recently-introduced breakage in psql's \connect command.

Through my misreading of what the existing code actually did,
commits 85c54287a et al. broke psql's behavior for the case where
"\c connstring" provides a password in the connstring.  We should
use that password in such a case, but as of 85c54287a we ignored it
(and instead, prompted for a password).

Commit 94929f1cf fixed that in HEAD, but since I thought it was
cleaning up a longstanding misbehavior and not one I'd just created,
I didn't back-patch it.

Hence, back-patch the portions of 94929f1cf having to do with
password management.  In addition to fixing the introduced bug,
this means that "\c -reuse-previous=on connstring" will allow
re-use of an existing connection's password if the connstring
doesn't change user/host/port.  That didn't happen before, but
it seems like a bug fix, and anyway I'm loath to have significant
differences in this code across versions.

Also fix an error with the same root cause about whether or not to
override a connstring's setting of client_encoding.  As of 85c54287a
we always did so; restore the previous behavior of overriding only
when stdin/stdout are a terminal and there's no environment setting
of PGCLIENTENCODING.  (I find that definition a bit surprising, but
right now doesn't seem like the time to revisit it.)

Per bug #16746 from Krzysztof Gradek.  As with the previous patch,
back-patch to all supported branches.

Discussion: http://postgr.es/m/16746-44b30e2edf4335d4@postgresql.org
doc/src/sgml/ref/psql-ref.sgml
src/bin/psql/command.c