aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-11-12 14:55:32 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2021-11-12 14:55:32 -0500
commitd6eb5a0c258d3da5471814bcc6ed6498129fee16 (patch)
treee9857937e0901833461e6ad3d0b9cf91493a0a76 /contrib/postgres_fdw
parentf8abb0f5e114d8c309239f0faa277b97f696d829 (diff)
downloadpostgresql-d6eb5a0c258d3da5471814bcc6ed6498129fee16.tar.gz
postgresql-d6eb5a0c258d3da5471814bcc6ed6498129fee16.zip
Make psql's \password default to CURRENT_USER, not PQuser(conn).
The documentation says plainly that \password acts on "the current user" by default. What it actually acted on, or tried to, was the username used to log into the current session. This is not the same thing if one has since done SET ROLE or SET SESSION AUTHENTICATION. Aside from the possible surprise factor, it's quite likely that the current role doesn't have permissions to set the password of the original role. To fix, use "SELECT CURRENT_USER" to get the role name to act on. (This syntax works with servers at least back to 7.0.) Also, in hopes of reducing confusion, include the role name that will be acted on in the password prompt. The discrepancy from the documentation makes this a bug, so back-patch to all supported branches. Patch by me; thanks to Nathan Bossart for review. Discussion: https://postgr.es/m/747443.1635536754@sss.pgh.pa.us
Diffstat (limited to 'contrib/postgres_fdw')
0 files changed, 0 insertions, 0 deletions