Re: Psql meta-command conninfo+

Hi,

I have attached a new patch that incorporates the approach suggested by
David. The documentation has also been updated.

$ bin/psql "port=5430 sslmode=disable dbname=postgres" -x -h localhost
psql (18devel)
Type "help" for help.

postgres=# \conninfo+
Connection Information
-[ RECORD 1 ]+----------
Database | postgres
Client User | hunaid
Host | localhost
Host Address | 127.0.0.1
Port | 5430
Options |

Current Status
-[ RECORD 1 ]--------+------
Protocol Version | 3
Password Used | false
GSSAPI Authenticated | false
Backend PID | 26268

Server Parameter Settings
-[ RECORD 1 ]---------+-------
Superuser | true
Client Encoding | UTF8
Server Encoding | UTF8
Session Authorization | hunaid

Connection Encryption
-[ RECORD 1 ]--+------
SSL Connection | false

$ bin/psql "port=5430 sslmode=require dbname=postgres" -x -h localhost
psql (18devel)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384,
compression: off, ALPN: postgresql)
Type "help" for help.

postgres=# \conninfo+ E
Connection Encryption
-[ RECORD 1 ]--+-----------------------
SSL Connection | true
Library | OpenSSL
Protocol | TLSv1.3
Key Bits | 256
Cipher | TLS_AES_256_GCM_SHA384
Compression | off
ALPN | postgresql

I’m unsure if we need to expand the documentation further. I would
appreciate your suggestions on this.

Regards,
Hunaid Sohail

On Mon, Oct 7, 2024 at 9:31 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Sun, Oct 6, 2024 at 11:17 PM Hunaid Sohail <hunaidpgml(at)gmail(dot)com>
> wrote:
>
>>
>> PQpass - no need
>>
>
> I would include this as presence/absence.
>
> I concur on all of the rest.
>
>
>>
>> For PQparameterStatus, some parameters are already used.
>> server_version and application_name were already discussed and removed in
>> v12 and v29 respectively. Do we need other parameters?
>>
>
> Ok, I'll need to go read the reasoning for why they are deemed unneeded
> and form an opinion one way or the other.
>
>
>>
>>> 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.
>>>
>>
>> 3 separate tables without suffix?
>>
>
> Yes, the tables need headers specific to their categories.
>
> I do like the idea of having 4 though, placing settings into their own.
> Premised on having all or most of the available parameters being on the
> table. If it only ends up being a few of them then keeping those in
> the status table makes sense.
>
> David J.
>
>>