Suggestions for improving \conninfo output in v18

On Sunday, June 1, 2025, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:

In v18, the "Protocol Version" column shown by \conninfo reports only
the major version (e.g., 3). Wouldn't it be more helpful to show the full
version (e.g., 3.2) using PQfullProtocolVersion()? Since support for
protocol version 3.2 was introduced in v18, users may want to know
exactly which version the current session is using.

This seems like a probable oversight that should be corrected.

Also, I noticed that the "Client User" column reflects the user at
the time of connection, while the "Superuser" column reflects whether
the current user in the current execution context is a superuser.
This means the users referred to in these columns can differ.
It might be worth aligning this behavior, or at least noting the
distinction
clearly in the documentation?

The behavior seems consistent with the reality of our protocol and libpq.
What did you have in mind for documentation changes?

David J.

On 2025/06/02 14:24, David G. Johnston wrote:

On Sunday, June 1, 2025, Fujii Masao <masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com>> wrote:

In v18, the "Protocol Version" column shown by \conninfo reports only
the major version (e.g., 3). Wouldn't it be more helpful to show the full
version (e.g., 3.2) using PQfullProtocolVersion()? Since support for
protocol version 3.2 was introduced in v18, users may want to know
exactly which version the current session is using.

This seems like a probable oversight that should be corrected.

Patch attached.

Also, I noticed that the "Client User" column reflects the user at
the time of connection, while the "Superuser" column reflects whether
the current user in the current execution context is a superuser.
This means the users referred to in these columns can differ.
It might be worth aligning this behavior, or at least noting the distinction
clearly in the documentation?

The behavior seems consistent with the reality of our protocol and libpq.  What did you have in mind for documentation changes?

How about adding a note like this?

----------------------
Note that the "Superuser" column does not necessarily reflect the privileges of the user shown in "Client User". "Client User" shows the user at the time of connection, while "Superuser" indicates whether the current user (in the current execution context) has superuser privileges. These users are usually the same, but they can differ, for example, if the current user was changed with the SET ROLE command.
----------------------

The same question also came up previously in [1]/messages/by-id/CAA5RZ0tbWopM83akPZ5M42V_RtyMTV8UfNUdE9LYw0YsPdOX5g@mail.gmail.com,
but seems no clear consensus was reached at that time.

Regards,

[1]: /messages/by-id/CAA5RZ0tbWopM83akPZ5M42V_RtyMTV8UfNUdE9LYw0YsPdOX5g@mail.gmail.com

--
Fujii Masao
NTT DATA Japan Corporation

On Sunday, June 1, 2025, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:

On 2025/06/02 14:24, David G. Johnston wrote:

On Sunday, June 1, 2025, Fujii Masao <masao.fujii@oss.nttdata.com
<mailto:masao.fujii@oss.nttdata.com>> wrote:

Also, I noticed that the "Client User" column reflects the user at

the time of connection, while the "Superuser" column reflects whether
the current user in the current execution context is a superuser.
This means the users referred to in these columns can differ.
It might be worth aligning this behavior, or at least noting the
distinction
clearly in the documentation?

The behavior seems consistent with the reality of our protocol and
libpq. What did you have in mind for documentation changes?

How about adding a note like this?

----------------------
Note that the "Superuser" column does not necessarily reflect the
privileges of the user shown in "Client User". "Client User" shows the user
at the time of connection, while "Superuser" indicates whether the current
user (in the current execution context) has superuser privileges. These
users are usually the same, but they can differ, for example, if the
current user was changed with the SET ROLE command.
----------------------

Where would you put that?

Right now there is zero documentation of \conninfo on the psql ref page
because it delegates all knowledge of its output to knowing various aspects
of libpq.

David J.

On 2025/06/02 21:53, David G. Johnston wrote:

On Sunday, June 1, 2025, Fujii Masao <masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com>> wrote:

On 2025/06/02 14:24, David G. Johnston wrote:

On Sunday, June 1, 2025, Fujii Masao <masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com> <mailto:masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com>>> wrote:

    Also, I noticed that the "Client User" column reflects the user at
    the time of connection, while the "Superuser" column reflects whether
    the current user in the current execution context is a superuser.
    This means the users referred to in these columns can differ.
    It might be worth aligning this behavior, or at least noting the distinction
    clearly in the documentation?

The behavior seems consistent with the reality of our protocol and libpq.  What did you have in mind for documentation changes?

How about adding a note like this?

----------------------
Note that the "Superuser" column does not necessarily reflect the privileges of the user shown in "Client User". "Client User" shows the user at the time of connection, while "Superuser" indicates whether the current user (in the current execution context) has superuser privileges. These users are usually the same, but they can differ, for example, if the current user was changed with the SET ROLE command.
----------------------

Where would you put that?

I was thinking to add a note to the \conninfo documentation, as shown
in the attached patch. I don't have a better alternative at the moment.

Regards,

--
Fujii Masao
NTT DATA Japan Corporation

On Tue, Jun 3, 2025 at 4:28 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:

On 2025/06/02 21:53, David G. Johnston wrote:

On Sunday, June 1, 2025, Fujii Masao <masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com>> wrote:

On 2025/06/02 14:24, David G. Johnston wrote:

On Sunday, June 1, 2025, Fujii Masao <masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com> <mailto:masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com>>> wrote:

Also, I noticed that the "Client User" column reflects the user at
the time of connection, while the "Superuser" column reflects whether
the current user in the current execution context is a superuser.
This means the users referred to in these columns can differ.
It might be worth aligning this behavior, or at least noting the distinction
clearly in the documentation?

The behavior seems consistent with the reality of our protocol and libpq. What did you have in mind for documentation changes?

How about adding a note like this?

----------------------
Note that the "Superuser" column does not necessarily reflect the privileges of the user shown in "Client User". "Client User" shows the user at the time of connection, while "Superuser" indicates whether the current user (in the current execution context) has superuser privileges. These users are usually the same, but they can differ, for example, if the current user was changed with the SET ROLE command.
----------------------

Where would you put that?

I was thinking to add a note to the \conninfo documentation, as shown
in the attached patch. I don't have a better alternative at the moment.

+1 on the idea to put it there; if someone gets confused about the
behavior, that seems like the place they'd go to look it up. Though I
would wordsmith the patch a little:

+          Note that the <structfield>Client User</structfield> field
shows the user at the time
+          of connection, while the
<structfield>Superuser</structfield> field indicates
+          whether the current user (in the current execution context) has
+          superuser privileges. These users are usually the same, but they can
+          differ, for example, if the current user was changed with the
+          <command>SET ROLE</command> command.

Robert Treat
https://xzilla.net

On 2025/06/03 20:22, Robert Treat wrote:

+1 on the idea to put it there; if someone gets confused about the
behavior, that seems like the place they'd go to look it up. Though I
would wordsmith the patch a little:

+          Note that the <structfield>Client User</structfield> field
shows the user at the time
+          of connection, while the
<structfield>Superuser</structfield> field indicates
+          whether the current user (in the current execution context) has
+          superuser privileges. These users are usually the same, but they can
+          differ, for example, if the current user was changed with the
+          <command>SET ROLE</command> command.

This looks good to me, thanks for the review! I've updated the patch (0002)
as you suggested and attached it.

I've also re-attached the 0001 patch that makes \conninfo report the full
protocol version, it's the same as the one I posted earlier in the thread.

Regards,

--
Fujii Masao
NTT DATA Japan Corporation

On 2025/06/04 20:18, Fujii Masao wrote:

On 2025/06/03 20:22, Robert Treat wrote:

+1 on the idea to put it there; if someone gets confused about the
behavior, that seems like the place they'd go to look it up. Though I
would wordsmith the patch a little:

+          Note that the <structfield>Client User</structfield> field
shows the user at the time
+          of connection, while the
<structfield>Superuser</structfield> field indicates
+          whether the current user (in the current execution context) has
+          superuser privileges. These users are usually the same, but they can
+          differ, for example, if the current user was changed with the
+          <command>SET ROLE</command> command.

This looks good to me, thanks for the review! I've updated the patch (0002)
as you suggested and attached it.

Barring any objections, I will commit this patch.

I've also re-attached the 0001 patch that makes \conninfo report the full
protocol version, it's the same as the one I posted earlier in the thread.

The 0001 patch changes \conninfo to report the full protocol version (e.g., 3.2)
instead of just the major version (e.g., 3). This is technically a behavior change,
but since protocol version 3.2 was introduced in v18, and both 3.0 and 3.2 are
now valid, always showing just "3" isn't very helpful. To see which protocol
version is actually in use, showing the full version is more informative.

Therefore I see this as fixing an oversight in commit bba2fbc6238, so I'd like to
commit the 0001 patch as well in v18. Thought?

Regards,

--
Fujii Masao
NTT DATA Japan Corporation

On Thu, Jun 12, 2025 at 8:05 PM Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:

On 2025/06/04 20:18, Fujii Masao wrote:

I've also re-attached the 0001 patch that makes \conninfo report the full
protocol version, it's the same as the one I posted earlier in the

thread.

The 0001 patch changes \conninfo to report the full protocol version
(e.g., 3.2)
instead of just the major version (e.g., 3). This is technically a
behavior change,
but since protocol version 3.2 was introduced in v18, and both 3.0 and 3.2
are
now valid, always showing just "3" isn't very helpful. To see which
protocol
version is actually in use, showing the full version is more informative.

Therefore I see this as fixing an oversight in commit bba2fbc6238, so I'd
like to
commit the 0001 patch as well in v18. Thought?

You should get the concurrence of the RMT. But given that the output is
new in v18 anyway my view is the original reworking of this view to be
tabular just chose the wrong field to display and that needs to be fixed.

Also, I was under the impression that updating relevant documentation for
a feature wasn't even subject to RMT review; i.e., 0002 should go in too if
it's otherwise committable. The feature it clarifies just changed/was
added so having our best docs present at release should be a project goal.

David J.

"David G. Johnston" <david.g.johnston@gmail.com> writes:

On Thu, Jun 12, 2025 at 8:05 PM Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:

Therefore I see this as fixing an oversight in commit bba2fbc6238, so I'd
like to commit the 0001 patch as well in v18. Thought?

You should get the concurrence of the RMT.
...
Also, I was under the impression that updating relevant documentation for
a feature wasn't even subject to RMT review;

FWIW, I agree with David's view of both of these points. RMT
review of 0001 should be a formality here, but nonetheless
we should adhere to process.

regards, tom lane

On 2025/06/13 13:32, Tom Lane wrote:

"David G. Johnston" <david.g.johnston@gmail.com> writes:

On Thu, Jun 12, 2025 at 8:05 PM Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:

Therefore I see this as fixing an oversight in commit bba2fbc6238, so I'd
like to commit the 0001 patch as well in v18. Thought?

You should get the concurrence of the RMT.
...
Also, I was under the impression that updating relevant documentation for
a feature wasn't even subject to RMT review;

FWIW, I agree with David's view of both of these points. RMT
review of 0001 should be a formality here, but nonetheless
we should adhere to process.

Agreed. Thanks to both of you for the comment!

I've added the RMT to CC. What do you think about including the 0001 patch in v18?
Would you be okay with that?

-----------------------
The 0001 patch changes \conninfo to report the full protocol version (e.g., 3.2)
instead of just the major version (e.g., 3). This is technically a behavior change,
but since protocol version 3.2 was introduced in v18, and both 3.0 and 3.2 are
now valid, always showing just "3" isn't very helpful. To see which protocol
version is actually in use, showing the full version is more informative.

Therefore I see this as fixing an oversight in commit bba2fbc6238, so I'd like to
commit the 0001 patch as well in v18. Thought?
-----------------------

Regards,

--
Fujii Masao
NTT DATA Japan Corporation

On Fri, Jun 13, 2025 at 06:52:26PM +0900, Fujii Masao wrote:

I've added the RMT to CC. What do you think about including the 0001 patch in v18?
Would you be okay with that?

-----------------------
The 0001 patch changes \conninfo to report the full protocol version (e.g., 3.2)
instead of just the major version (e.g., 3). This is technically a behavior change,
but since protocol version 3.2 was introduced in v18, and both 3.0 and 3.2 are
now valid, always showing just "3" isn't very helpful. To see which protocol
version is actually in use, showing the full version is more informative.

Therefore I see this as fixing an oversight in commit bba2fbc6238, so I'd like to
commit the 0001 patch as well in v18. Thought?
-----------------------

Sounds good to me.

--
nathan

On 2025/06/13 22:50, Nathan Bossart wrote:

On Fri, Jun 13, 2025 at 06:52:26PM +0900, Fujii Masao wrote:

I've added the RMT to CC. What do you think about including the 0001 patch in v18?
Would you be okay with that?

-----------------------
The 0001 patch changes \conninfo to report the full protocol version (e.g., 3.2)
instead of just the major version (e.g., 3). This is technically a behavior change,
but since protocol version 3.2 was introduced in v18, and both 3.0 and 3.2 are
now valid, always showing just "3" isn't very helpful. To see which protocol
version is actually in use, showing the full version is more informative.

Therefore I see this as fixing an oversight in commit bba2fbc6238, so I'd like to
commit the 0001 patch as well in v18. Thought?
-----------------------

Sounds good to me.

Thanks for confirming! I've now pushed the 0001 patch.

As discussed earlier, I've also committed the 0002 patch.

Regards,

--
Fujii Masao
NTT DATA Japan Corporation