From: | Maiquel Grassi <grassi(at)hotmail(dot)com(dot)br> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | Hunaid Sohail <hunaidpgml(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, Erik Wienhold <ewie(at)ewie(dot)name>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Subject: | Re: Psql meta-command conninfo+ |
Date: | 2025-01-20 13:34:22 |
Message-ID: | CP4P284MB1968F17B9DFA96A5D6529C94ECE72@CP4P284MB1968.BRAP284.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>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+.
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.
Regards,
Maiquel.
From | Date | Subject | |
---|---|---|---|
Next Message | m.litsarev | 2025-01-20 13:49:45 | pg_stat_statements: improve loading and saving routines for the dump file |
Previous Message | Bertrand Drouvot | 2025-01-20 13:26:55 | Re: per backend I/O statistics |