Re: Psql meta-command conninfo+

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(at)hotmail(dot)com(dot)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.
>