Re: is_superuser is not documented - Mailing list pgsql-hackers

From Tom Lane
Subject Re: is_superuser is not documented
Date
Msg-id 161892.1662743776@sss.pgh.pa.us
Whole thread Raw
In response to Re: is_superuser is not documented  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: is_superuser is not documented
List pgsql-hackers
I wrote:
> On the other hand, it seems pretty silly that it's GUC_REPORT if
> we want to consider it private.  I've not checked the git history,
> but I bet that flag was added later with no thought about context.
>
> If we are going to document this then we should at least remove
> the GUC_NO_SHOW_ALL flag and rewrite the comment.  I wonder whether
> the GUC_NO_RESET_ALL flag is needed either --- seems like the
> PGC_INTERNAL context protects it sufficiently.

BTW, "session_authorization" has a subset of these same issues:

        /* Not for general use --- used by SET SESSION AUTHORIZATION */
        {"session_authorization", PGC_USERSET, UNGROUPED,
            gettext_noop("Sets the session user name."),
            NULL,
            GUC_IS_NAME | GUC_REPORT | GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE |
GUC_NOT_WHILE_SEC_REST
        },
        &session_authorization_string,
        NULL,
        check_session_authorization, assign_session_authorization, NULL

I wonder why this one is marked USERSET where the other is not.
You'd think both of them need similar special-casing about how
to handle SET.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.
Next
From: Nathan Bossart
Date:
Subject: Re: Possible crash on standby