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

From Hunaid Sohail
Subject Re: Psql meta-command conninfo+
Date
Msg-id CAMWA6yYpof0a1CZ-SDHcHqbdnRfh7oby-GpM7b5XVdLpoHMmpw@mail.gmail.com
Whole thread Raw
In response to RE: Psql meta-command conninfo+  (Maiquel Grassi <grassi@hotmail.com.br>)
List pgsql-hackers
Hi,

I have read the entire thread discussion. I understood the importance of this enhancement related to /conninfo+ meta command. I really appreciate the efforts of Maiquel and suggestions made by the reviewers. According to best of my understanding, libpq API should be used instead of creating server query for conninfo+ meta command. Building on the patch (v29) provided by Maiquel, I made changes to retrieve some extra information related to connection from libpq API.

Extra information includes:
- Protocol Version
- SSL Connection
- GSSAPI Authenticated
- Client Encoding
- Server Encoding
- Session User
- Backend PID

Output of \conninfo+:
  1. $ bin/psql --port=5430 postgres -h localhost psql (18devel) Type "help" for help. postgres=# \conninfo+ You are connected to database "postgres" as user "hunaid" on host "localhost" (address "127.0.0.1") at port "5430". Protocol Version: 3 SSL Connection: no GSSAPI Authenticated: no Client Encoding: UTF8 Server Encoding: UTF8 Session User: hunaid Backend PID: 163816

I have also edited the documentation and added it to the patch. Please let me know if any changes are required.

Regards,
Hunaid Sohail

On Wed, Jun 5, 2024 at 5:32 PM Maiquel Grassi <grassi@hotmail.com.br> wrote:
From a quick skim of the latest messages in this thread, it sounds like
there are a couple of folks who think \conninfo (and consequently
\conninfo+) should only report values from the libpq API.  I think they
would prefer server-side information to be provided via a system view or
maybe an entirely new psql meta-command.

IIUC a new system view would more-or-less just gather information from
other system views and functions.  A view would be nice because it could be
used outside psql, but I'm not sure to what extent we are comfortable
adding system views built on other system views.  Something like
\sessioninfo (as proposed by Sami) would look more similar to what you have
in your latest patch, i.e., we'd teach psql about a complicated query for
gathering all this disparate information.

IMHO a good way to help move this forward is to try implementing it as a
system view so that we can compare the two approaches.  I've had luck in
the past with implementing something a couple different ways to help drive
consensus.

--//--

Great Nathan, we can follow that path of the view. I leave it open for anyone in the thread who has been following from the beginning to start the development of the view. Even you, if you have the interest and time to do it. At this exact moment, I am involved in a "my baby born" project, so I am unable to stop to look into this. If someone wants to start, I would appreciate it.
Regards,
Maiquel Grassi.
Attachment

pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: CI, macports, darwin version problems
Next
From: Robert Haas
Date:
Subject: Re: On disable_cost