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

From Hunaid Sohail
Subject Re: Psql meta-command conninfo+
Date
Msg-id CAMWA6yZ=X=11ccJH86SDOOP-QCQp7Z3bHSWjJNOzxfnNF=OXYg@mail.gmail.com
Whole thread Raw
In response to Re: Psql meta-command conninfo+  (Maiquel Grassi <grassi@hotmail.com.br>)
List pgsql-hackers
Hi,

On Mon, Jan 20, 2025 at 6:34 PM Maiquel Grassi <grassi@hotmail.com.br> wrote:
>That leads me to also wonder why don't we change \conninfo to have this
>tabular behavior instead of creating a separate command for it.  Why do
>we need to keep the existing form of \conninfo?  To me it seems strictly
>less useful, as it is harder to read.

Here, you're suggesting that it would be useful to keep the \conninfo
meta-command, improve it with a "new version," and display the returned
content as a table instead of text. If that's the case, I think it's a good idea
since it would show the "new settings" that the current version doesn't
display and, yes, it would serve the same purpose as \conninfo+.

Sure, we can proceed with that. I do hope this will be the final one we try :)
 
Regarding which settings to display, the discussion tends to get very broad,
and we can never settle on what should be shown definitively. I believe
that, often, less is more, so showing only the essential settings would be
enough.

In that case, we can collectively decide which parameters should be shown
in this command. My suggestion:
- application_name
- encodings (maybe?)
- role (new patch)
- is_superuser
- session_authorization
- in_hot_standby

Feel free to suggest any additions or removals.

Regards,
Hunaid Sohail 

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: table_tuple_lock's snapshot argument
Next
From: Ashutosh Bapat
Date:
Subject: Re: pgbench without dbname worked differently with psql and pg_dump