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

From David G. Johnston
Subject Re: Psql meta-command conninfo+
Date
Msg-id CAKFQuwb_R-zGT41xsBkPChBEB9e=A4P3fsAGjeqOzTuWN1Z5Sg@mail.gmail.com
Whole thread Raw
In response to Re: Psql meta-command conninfo+  (Hunaid Sohail <hunaidpgml@gmail.com>)
Responses Re: Psql meta-command conninfo+
List pgsql-hackers
On Thursday, October 3, 2024, Hunaid Sohail <hunaidpgml@gmail.com> wrote:

Authenticated User: The name of the user returned by PQuser(), indicating the user who initiated or authenticated the current database connection.
Session User: The session user's name, which is initially the same as the authenticated user but can be changed with SET SESSION AUTHORIZATION. See the session_user() function in <xref linkend="functions-info-session-table"/> for more details.


It seems to me a more useful definition for what this command should print out is basically the entire contents of:


That page has three sections:
Connection Invariants
Current Status
Encryption (TLS)

I would suggest that we thus produce three tables - one for each.  In the case of SSL, a message saying “not used” instead of a table full of blanks probably suffices, though I’d lean to print all of what is available at all times.

Within that framework having \conninfo[+[CSE][…]] be the command - printing out only the table specified would be the behavior (specifying no suffix letters prints all three) - would be an option.

We could add a fourth table - Parameters (P) - for the various outputs of PQparameterStatus; thus making the Current Status section a bit more manageable

There are obviously some things psql wouldn’t expose (like password) - we should probably list them explicitly in an exception list, and maybe note as much on the libpq page.

Separately, I don’t see a reason to even show “Authenticated User” unless it is different than Session User - which means only in the rare case of a superuser invoking set session authorization.  It also isn’t guaranteed to be authenticated, which the docs do try to make a point of, so “Client User” would be more appropriate.

David J.

pgsql-hackers by date:

Previous
From: Hunaid Sohail
Date:
Subject: Re: Psql meta-command conninfo+
Next
From: Ivan Kush
Date:
Subject: Re: Replace IN VALUES with ANY in WHERE clauses during optimization