Re: Psql meta-command conninfo+

From: Hunaid Sohail <hunaidpgml(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Maiquel Grassi <grassi(at)hotmail(dot)com(dot)br>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Subject: Re: Psql meta-command conninfo+
Date: 2025-01-09 05:53:41
Message-ID: CAMWA6yYZeVkWNL=GXcR_pJL=QYQntdJp4ba-pA7gj9A0JJNyMQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

After looking at this ever more today, I think "Server Parameter Settings"
> is confusing as well. I think "Connection Status" instead of
> "Current Status" as is defined in v36 will work better.
> This way we will have "Connection Info" and "Connection Status".
> Connection Status will reflect the values of specific parameters
> that the server reports.
>

Noted.

> Including all the parameters in [1] under
> "Server Parameter Settings" (or "Connection Status")
> seems like the easy choice here. Some may not be as useful as
> others, but I don't think we should pick and choose either.
> Maybe someone else has other thoughts about this?
>

Sure, let's wait for others' opinions.

> We can include role by marking the "role" guc with
> the GUC_REPORT flag in guc_tables.c. I really think
> without it, the is_superuser field will be incomplete.
> This is because either "role" or "session authorization"
> will change the is_superuser.
>

Thanks! I will take a look.

> A thought also, that if we do choose to report all the parameters
> in [1], it should be coded in a more dynamic way. Maybe loop
> through the conn->pstatus list? For example I see "search_path"
> will be added to the list in the next release.
>

If we loop through conn->pstatus, we will be bypassing the official API.
The list is of type pgParameterStatus, which is an internal struct defined
in libpq-int.h.
As the file's header warns, including this file can lead to issues. Or am I
missing something?

Regards,
Hunaid Sohail

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2025-01-09 05:57:11 Re: Re: proposal: schema variables
Previous Message Amit Kapila 2025-01-09 05:50:21 Re: Conflict detection for update_deleted in logical replication