Re: Psql meta-command conninfo+ - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Psql meta-command conninfo+
Date
Msg-id 1c721769-fbb1-4a76-bde6-d9cc144f20e7@eisentraut.org
Whole thread Raw
In response to RE: Psql meta-command conninfo+  (Maiquel Grassi <grassi@hotmail.com.br>)
Responses Re: Psql meta-command conninfo+
List pgsql-hackers
On 04.04.24 18:15, Maiquel Grassi wrote:
> Well, I can revert \conninfo to its original state and keep \conninfo+
> as it is, perhaps removing the application name, as I believe everything
> else is important for a DBA/SysAdmin. Do you think we can proceed
> with the patch this way? I am open to ideas that make \conninfo not
> limited to just four or five basic pieces of information and easily bring
> everything else to the screen.

The original \conninfo was designed to report values from the libpq API 
about what libpq connected to.  And the convention in psql is that "+" 
provide more or less the same information but a bit more.  So I think it 
is wrong to make "\conninfo+" something fundamentally different than 
"\conninfo".

And even more so if it contains information that isn't really 
"connection information".  For example, current_user() doesn't make 
sense here, I think.

I mean, if you want to add a command \some_useful_status_information, we 
can talk about that, but let's leave \conninfo to what it does.

But I think there are better ways to implement this kind of server-side 
status, for example, with a system view.

One problem in this patch is that it has no tests.  Any change in any of 
the involved functions or views will silently break this.  (Note that 
plain \conninfo doesn't have this problem to this extent because it only 
relies on libpq function calls.  Also, a system view would not have this 
problem.)




pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: Robert Haas
Date:
Subject: Re: documentation structure