Re: Fix output of zero privileges in psql - Mailing list pgsql-hackers

On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote:
> 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.

Ah, sorry, I misread your comment.  You are right.  But then, the effects of
ALTER DEFAULT PRIVILEGES are discussed later in the paragraph anyway, and we don't
have to repeat that here.

> >
> > 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.

Again, you have a point there.  However, I find that detail useful, as it explains
the user-facing behavior.  Anyway, I don't think it is the job of this patch to
remove that pre-existing detail.

> > 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.

Thanks.  Then let's leave it like that.

> 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.

-1

The whole point of this patch is to make psql behave consistently with respect to
NULLs in meta-commands.  Your suggestion would subvert that idea.

Yours,
Laurenz Albe