Thread: Re: Suggestions for improving \conninfo output in v18
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 documentationchanges? 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". "ClientUser" shows the user at the time of connection, while "Superuser" indicates whether the current user (in the currentexecution context) has superuser privileges. These users are usually the same, but they can differ, for example, ifthe 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
Attachment
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 documentationchanges? > > > > > > 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 thecurrent 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
Attachment
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.
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