Horton

Thread

Commits

  1. doc: Add note about "Client User" and "Superuser" fields in \conninfo output.

  2. psql: Report full protocol version in \conninfo output.

  3. Change \conninfo to use tabular format

  1. Suggestions for improving \conninfo output in v18

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2025-06-02T04:48:25Z

    Hi,

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.

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?

Regards,

-- 
Fujii Masao
NTT DATA Japan Corporation

  2. Re: Suggestions for improving \conninfo output in v18

    David G. Johnston <david.g.johnston@gmail.com> — 2025-06-02T05:24:15Z

    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.

  3. Re: Suggestions for improving \conninfo output in v18

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2025-06-02T06:39:54Z

    
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],
but seems no clear consensus was reached at that time.

Regards,

[1] https://www.postgresql.org/message-id/CAA5RZ0tbWopM83akPZ5M42V_RtyMTV8UfNUdE9LYw0YsPdOX5g%40mail.gmail.com

-- 
Fujii Masao
NTT DATA Japan Corporation

  4. Re: Suggestions for improving \conninfo output in v18

    David G. Johnston <david.g.johnston@gmail.com> — 2025-06-02T12:53:35Z

    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.

  5. Re: Suggestions for improving \conninfo output in v18

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2025-06-03T08:28:14Z

    
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

  6. Re: Suggestions for improving \conninfo output in v18

    Robert Treat <rob@xzilla.net> — 2025-06-03T11:22:51Z

    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

  7. Re: Suggestions for improving \conninfo output in v18

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2025-06-04T11:18:13Z

    
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

  8. Re: Suggestions for improving \conninfo output in v18

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2025-06-13T03:05:53Z

    
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

  9. Re: Suggestions for improving \conninfo output in v18

    David G. Johnston <david.g.johnston@gmail.com> — 2025-06-13T03:57:45Z

    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.

  10. Re: Suggestions for improving \conninfo output in v18

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-06-13T04:32:52Z

    "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

  11. Re: Suggestions for improving \conninfo output in v18

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2025-06-13T09:52:26Z

    
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

  12. Re: Suggestions for improving \conninfo output in v18

    Nathan Bossart <nathandbossart@gmail.com> — 2025-06-13T13:50:46Z

    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

  13. Re: Suggestions for improving \conninfo output in v18

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2025-06-14T01:41:55Z

    
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