Date: Tue, 8 Jul 2025 17:41:32 -0700
From: Noah Misch <noah@leadboat.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Michael Banck <mbanck@gmx.net>,
	Greg Sabino Mullane <htamfids@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [PATCH] Add support for displaying database service in psql
 prompt
Message-ID: <20250709004132.db.nmisch@google.com>
References: <6748cfd4.050a0220.1537dc.43bb@mx.google.com>
 <Z1fv8D_t1ok8svgO@paquier.xyz>
 <6760a25e.a70a0220.2e9d8f.d542@mx.google.com>
 <Z2ErmZD1lImYt_as@paquier.xyz>
 <6761397c.df0a0220.68885.210d@mx.google.com>
 <Z2JpAD4395C-qALl@paquier.xyz>
 <20250706161319.c1.nmisch@google.com>
 <aGsrjkNUaqmDgbK8@paquier.xyz>
 <20250707030009.b8.nmisch@google.com>
 <aGxdqG-tibbxXY1D@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aGxdqG-tibbxXY1D@paquier.xyz>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: 
 <https://www.postgresql.org/message-id/20250709004132.db.nmisch%40google.com>
Precedence: bulk

On Tue, Jul 08, 2025 at 08:52:08AM +0900, Michael Paquier wrote:
> On Sun, Jul 06, 2025 at 08:00:09PM -0700, Noah Misch wrote:
> > I think the choice to make there is whether to call PQconninfo() once per
> > prompt emission or to cache the value, invalidating that cache e.g. once per
> > SyncVariables().  My first thought was to cache, but the decision is not too
> > important.  A PQconninfo() call is likely negligible relative to all that
> > happens between prompts.  Even if not negligible, the overhead of not caching
> > will affect only prompts using the new escape sequence.
> 
> SyncVariables() happens at startup and when re-syncing a connection
> during a check, so that does not really worry me.
> 
> By the way, there is a second change in the CF that's suggesting the
> addition of a SERVICEFILE variable, which also uses a separate libpq
> API (forgot about this one):
> https://commitfest.postgresql.org/patch/5387/
> 
> Changing the patch on the other thread to use a conninfo is
> stright-forward.  How about extending the get_service_name()@common.c
> I've proposed upthread so as it takes a string in input and it could
> be reused for more connection options than only "service" so as it
> could be reused there as well?

I'd prefer not to get involved in decisions affecting only psql efficiency and
psql code cosmetics.  Please make that decision without my input.