BUG #16936: psql: \c service= not working
The following bug has been logged on the website:
Bug reference: 16936
Logged by: Jasen Betts
Email address: pg_bugs@revmaps.no-ip.org
PostgreSQL version: 13.2
Operating system: Linux Debian 10.8 on amd64
Description:
The \c metacommand in psql does not anymore use the full information from
pg_service.conf
It's reading the pg_service.conf file but seems to ignore everything but the
dbname=part part of the entry. this bug seems to be new, but is possibly not
in the psql binary itself, as the bug seems to have at-least partially
migrated to older versions of psql too.
The following is a verbatim transcript except for the initial secret
connection string. obviously the service entry for "[j]" is broken on every
line except dbname, yet all those lines are being ignored.
jasen@ryan:~$ psql 'secret-connection-string deleted'
psql (13.2 (Debian 13.2-1.pgdg100+1), server 10.16 (Debian
10.16-1.pgdg90+1))
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384,
bits: 256, compression: off)
Type "help" for help.
back2=> \c service=j
psql (13.2 (Debian 13.2-1.pgdg100+1), server 11.10 (Debian
11.10-1.pgdg100+1))
You are now connected to database "jasen" as user "jasen" via socket in
"/var/run/postgresql" at port "5432".
jasen=# \q
jasen@ryan:~$ psql service=j
psql: error: received invalid response to SSL negotiation: H
jasen@ryan:~$ cat .pg_service.conf
[j]
host=example.com
dbname=jasen
user=nobody
password=paternal_gladius
port=80
jasen@ryan:~$
PG Bug reporting form <noreply@postgresql.org> writes:
The \c metacommand in psql does not anymore use the full information from
pg_service.conf
It's reading the pg_service.conf file but seems to ignore everything but the
dbname=part part of the entry. this bug seems to be new, but is possibly not
in the psql binary itself, as the bug seems to have at-least partially
migrated to older versions of psql too.
Hmm, I suppose this has something to do with the fixes for bug #16604 [1]/messages/by-id/16604-933f4b8791227b15@postgresql.org.
Those were not supposed to affect the behavior for -reuse-previous=off
cases, which yours should be since there's an "=" in the \c argument.
However, after poking at it for a bit, I have a theory: are the
service-file entries that aren't being honored overridden by variables
from your environment (PGPORT etc)? I think that patch may have
unintentionally changed the relative priority of service file entries
versus other sources of default values.
regards, tom lane