>> I think "Connection Encryption" seems unnecessary here as
>> well and it could be added to "Connection Information".
>
>
> Yes, we can do that, but we’d be left with two tables:
> "Connection Information" and "Server Parameter Settings". Does that work?
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.
>
>> "Server Parameter Settings": This section should include
>> all under [1]. For example, "in_hot_standby" is very
>> useful, and so is "application_name". Why are they
>> not included?
>
>
> There was a discussion about "application_name" earlier in the thread, and it was removed by the original author.
> However, since we now have a separate table, it makes sense to include all parameters.
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?
> Agreed. However, since we're using the libpq API, I don't think we can retrieve the role name.
> Maybe remove "Session Authorization" instead?
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.
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.
[1] https://www.postgresql.org/docs/devel/libpq-status.html
Regards,
Sami
