Subject: Re: Psql meta-command conninfo+

From: Hunaid Sohail <[email-masked]>
Date: Fri, 10 Jan 2025 12:47:35 +0500

Hi,

On Fri, Jan 10, 2025 at 1:50 AM Sami Imseih <[email-masked]> wrote:

> > If we go with the 3 column format, then we will just
> > have a bunch of repeated values for Category, which
> > looks cluttered, IMO.
>
> "cluttered" is maybe the wrong description. I meant the output
> will look overwhelming due to the repeated values :)
>

+1.

To summarize:

- Alvaro is not happy with \conninfo+ printing multiple tables and suggests
we continue with v35.

- Sami is ok with both approaches but thinks that \conninfo+ should also
print all parameters from PQparameterStatus in a dynamic way. Also, he
suggests to include "role" if we are showing is_superuser.
For that, we need two more patches:
1. Mark role as GUC_REPORT with necessary doc changes.
2. Add a new libpq function (perhaps PQparameterNames) to return the names
of parameters, so we can also display parameters added in the future,
along with doc updates.

- David wants category information included.

IMO, we should continue with v35 and add all parameters from
PQparameterStatus,
as Sami suggested. The names themselves are informative enough.

Looking forward to your feedback.

Regards,
Hunaid Sohail

---

From: Alvaro Herrera <[email-masked]>
Date: Mon, 13 Jan 2025 09:44:30 +0100

> as Sami suggested. The names themselves are informative enough.

IMO we need more opinions.  Maybe enough other people are not as unhappy
about the three-table solution.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/

---

From: Dean Rasheed <[email-masked]>
Date: Mon, 13 Jan 2025 11:12:23 +0000

> about the three-table solution.

I don't like the 3-table format either. I think it should be a single table.

The trouble with v35 is that it produces 1 row with lots of columns,
which is pretty unreadable unless expanded mode is used. So I think we
should just do it that way round by default -- i.e., make it like
\dconfig and have 2 columns, "Parameter" and "Value", with lots of
rows.

Perhaps it could also have a "Description" column, which might help
with things like distinguishing between authenticated user and session
user.

Regards,
Dean

---

From: Hunaid Sohail <[email-masked]>
Date: Tue, 14 Jan 2025 12:57:29 +0500

Hi,

> with things like distinguishing between authenticated user and session

I've tried the approach and attached the output.
I'm not attaching the patch as it requires some formatting. Does this look
good?
I have added a one liner description that is consistent with libpq docs.

postgres=# \conninfo+
                                                     Connection Information
      Parameter       |         Value          |
       Description
----------------------+------------------------+--------------------------------------------------------------------------------
 Database             | postgres               | Displays the database name
of the connection.
 Client User          | hunaid                 | Displays the name of the
user connected to the database as returned by PQuser.
 Host                 | localhost              | Displays the server host
name of the active connection.
 Host Address         | 127.0.0.1              | Displays the server IP
address of the active connection.
 Port                 | 5430                   | Displays the port number
used for the database connection.
 Options              |                        | Displays any command-line
options passed in the connection request.
 Protocol Version     | 3                      | Displays the
frontend/backend protocol being used.
 Password Used        | false                  | Indicates whether a
password was used during authentication.
 GSSAPI Authenticated | false                  | Indicates if GSSAPI
authentication was used for the connection.
 Backend PID          | 43465                  | Displays the process ID of
the backend for the connection.
 SSL Connection       | true                   | Indicates whether SSL
encryption is in use for the connection.
 SSL Protocol         | TLSv1.3                | Displays the SSL protocol
used for the connection.
 SSL Cipher           | TLS_AES_256_GCM_SHA384 | Displays the SSL cipher
used for the connection.
 SSL Compression      | off                    | Indicates whether SSL
compression is enabled.
 ALPN                 | postgresql             | Displays the ALPN protocol
used in the SSL connection.
(15 rows)

I was wondering how we can show the descriptions of parameters
from PQparameterStatus. We can create an array of descriptions,
but if the order changes somehow, it can mess things up.

Looking forward to your opinions. Can we continue with this approach?

Regards,
Hunaid Sohail

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 14 Jan 2025 09:51:45 +0100

On 2025-Jan-14, Hunaid Sohail wrote:

> I'm not attaching the patch as it requires some formatting.

Remember pgindent formats code in bulk.  A quick useful workflow is to
do that first, apply manual adjustments next, run pgindent again
afterwards.

> I've tried the approach and attached the output.  Does this look good?

Hmm, I'm not sure I like the third column particularly; it's noisy to
have on all the time.  I'd leave that for \conninfo++ maybe :-)

_If_ we keep the descriptions, I suggest that the majority need to be
very short, say three words tops, with exceptions allowed for egregious
cases (if any).  We should get rid of filler words such as "Displays
the" or "Indicates whether".  For instance, I'd turn "Indicates if
GSSAPI authentication was used for the connection" into "GSSAPI
authenticated?" which conveys exactly the same; the ending "?" matches
things like "Key?" in \d of an index or the "Default?" column in \dc.
It's a boolean, so people know how to read it.

> but if the order changes somehow, it can mess things up.

Definitely avoid writing code that can easily be broken by later changes
(future parameter additions and so on).

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"The problem with the facetime model is not just that it's demoralizing, but
that the people pretending to work interrupt the ones actually working."
                  -- Paul Graham, http://www.paulgraham.com/opensource.html