From: Tom Lane <tgl@sss.pgh.pa.us>
To: pg_bugs@revmaps.no-ip.org
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16936: psql: \c service= not working
In-reply-to: <16936-3f524322a53a29f0@postgresql.org>
References: <16936-3f524322a53a29f0@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 22 Mar 2021 02:32:56 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <809835.1616464184.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 22 Mar 2021 21:49:44 -0400
Message-ID: <809836.1616464184@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/809836.1616464184%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The \c metacommand in psql does not anymore use the full information fro=
m
> pg_service.conf
> It's reading the pg_service.conf file but seems to ignore everything but=
 the
> dbname=3Dpart part of the entry. this bug seems to be new, but is possib=
ly 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].
Those were not supposed to affect the behavior for -reuse-previous=3Doff
cases, which yours should be since there's an "=3D" 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

[1] https://www.postgresql.org/message-id/flat/16604-933f4b8791227b15%40po=
stgresql.org