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 <gra...@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. >
ÿþ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 <