On Tue, Apr 11, 2023 at 9:37 AM Fujii Masao <
masao.fujii@oss.nttdata.com> wrote:
> > > Yes, this patch moves the descriptions of is_superuser to config.sgml
> > > and changes its group to PRESET_OPTIONS.
> >
> > is_superuser feels a little out of place in this file. All of
> > the options here apply to the entire PostgreSQL server, while
> > is_superuser only applies to the current session.
>
> Aren't other preset options like lc_collate, lc_ctype and server_encoding
> similar to is_superuser? They seem to behave in a similar way as their
> settings can be different for each connection depending on the connected database.
I think the difference is that all of those options are constant for
all connections to the same database and once the database is created
they are immutable. is_superuser is set on a per session basis and can
be changed at any time.
Looking through the options it actually looks like all the options are
set either when the server is built, the server is started, or the
database is created, and once they're set they become immutable. The
one exception I see is in_hot_standby mode which can be updated from on
to off (I can't remember off the top of my head if it can be updated
the other way). I'm moving the goal post a bit but I think preset may
imply that the value isn't going to change once it's been set.
Having said all that I actually think this is the best place for
is_superuser since it doesn't seem to fit in anywhere else.
> > I'm not familiar with the origins of is_superuser and it may be too
> > late for this, but it seems like is_superuser would fit in much better
> > as a system information function [0] rather than a GUC. Particularly
> > in the Session Information Functions.
>
> I understand your point, but I think it would be more confusing to document
> is_superuser there because it's defined and behaves differently from
> session information functions like current_user. For instance,
> the value of is_superuser can be displayed using SHOW command,
> while current_user cannot. Therefore, it's better to keep is_superuser
> separate from the session information functions.
I was implying that I thought it would have made more sense for
is_superuser to be implemented as a function, behave as a function,
and not be visible via SHOW. However, there may have been a good reason
not to do this and it may already be too late for that.
In my opinion, this is ready to be committed. However, like I said
earlier I'm not very familiar with the GUC code so you may want to
wait for another opinion.
Thanks,
Joe Koshakow
