Re: Fix output of zero privileges in psql

On Mon, Oct 9, 2023 at 1:29 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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.