Re: [PATCH] Add support for displaying database service in psql prompt
Noah Misch <noah@leadboat.com>
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>
Date: 2025-07-09T00:41:32Z
Lists: pgsql-hackers
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.
Commits
-
libpq: Remove PQservice()
- fc3edb52fbb9 18.0 landed
- fef6da9e9c87 19 (unreleased) landed
-
psql: Add more information about service name
- 477728b5d6fa 18.0 landed
-
libpq: Add service name to PGconn and PQservice()
- 4b99fed7541e 18.0 cited