Re: Fix output of zero privileges in psql - Mailing list pgsql-hackers
| From | David G. Johnston |
|---|---|
| Subject | Re: Fix output of zero privileges in psql |
| Date | |
| Msg-id | CAKFQuwY9e+xPMTwVcf3T2eNwFe1WZbMcWu026yh-Lfk5Tn_J2Q@mail.gmail.com Whole thread Raw |
| In response to | Re: Fix output of zero privileges in psql (Laurenz Albe <laurenz.albe@cybertec.at>) |
| Responses |
Re: Fix output of zero privileges in psql
|
| List | pgsql-hackers |
On Mon, Oct 9, 2023 at 1:29 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Sun, 2023-10-08 at 19:58 -0700, David G. Johnston wrote:
> The built-in default privileges are only in effect if the object has not been
> the target of a GRANT or REVOKE and also has not had its default privileges
> modified using ALTER DEFAULT PRIVILEGES. (???: if it is possible to revert
> back to the state of built-in privileges that would need to be described here.)
I don't think that we need to mention ALTER DEFAULT PRIVILEGES there. If
the default privileges have been altered, the ACL will not be stored as
NULL in the catalogs.
It's already mentioned there, I just felt bringing the mention of ADP and grant/revoke both invalidating the built-in default privileges closer together would be an improvement.
> The above removes the parenthetical regarding null in the catalogs, this is
> intentional as it seems that the goal here is to use psql instead of the
> catalogs and adding its use of null being printed as the empty string just
> seems likely to add confusion.
To me, mentioning the default privileges are stored as NULLs in the catalogs
is not an invitation to view the privileges with catalog queries, but
information about implementation details that explains why default privileges
are displayed the way they are.
Calling it an implementation detail leads me to conclude the point does not belong in the user-facing administration documentation.
> > > Perhaps it would also be good to mention this in the psql documentation.
>
> We've chosen a poor default and I'd rather inform the user of specific meta-commands
> to be wary of this poor default and change it at the point they will be learning
> about the meta-commands adversely affected.
>
> That said, I'd be willing to document that these commands, because they are affected
> by empty string versus null, require a non-empty-string value for \pset null and will
> choose the string '<null>' for the duration of the meta-command's execution if the
> user's setting is incompatible.
I am not certain I understood you correctly.
Are you advocating for adding a mention of "\pset null" to every backslash command
that displays privileges? That is excessive, in my opinion.
Yes, I am. I suppose the argument that any user of those commands is expected to have read the ddl/privileges chapter would suffice for me though.
My point with the second paragraph is that we could, instead of documenting the caveat about null printing as empty strings is to instead issue an implicit "\pset null '<null>'" as part of these commands, and a "\pset null" afterward, conditioned upon it not already being set to a non-empty value. IOW, the special-casing we do today but actually do it in a way that distinguishes the two cases instead of forcing them to be indistinguishable.
David J.
pgsql-hackers by date: