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 <[email protected]> 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.
>
��d i f f - - g i t a / d o c / s r c / s g m l / r e f / p s q l - r e f . s g m l b / d o c / s r c / s g m l / r e f / p s q l - r e f . s g m l
i n d e x 0 7 4 1 9 a 3 b 9 2 . . f b 3 d 5 2 f b 1 6 1 0 0 6 4 4
- - - a / d o c / s r c / s g m l / r e f / p s q l - r e f . s g m l
+ + + b / d o c / s r c / s g m l / r e f / p s q l - r e f . s g m l
@ @ - 1 0 3 0 , 1 1 + 1 0 3 0 , 2 9 @ @ I N S E R T I N T O t b l 1 V A L U E S ( $ 1 , $ 2 ) \ b i n d ' f i r s t v a l u e ' ' s e c o n d v a l u e ' \ g
<