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

From Tom Lane
Subject Re: Fix output of zero privileges in psql
Date
Msg-id 377395.1698073029@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fix output of zero privileges in psql  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Fix output of zero privileges in psql
List pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> We document default privileges print as an empty string - I do not think we
> should change the definition to "default privileges print null which can be
> controlled via \pset null", and regardless of preference doing so is not a
> bug.

Well, "if it's documented it's not a bug" is a defensible argument
for calling something not a bug, but it doesn't address the question
of whether changing it would be an improvement.  I think it would be,
and I object to your claim that we have a consensus to not do that.

The core of the problem here, IMO, is exactly that there is confusion
between whether a visibly empty string represents NULL (default
privileges) or an empty ACL (no privileges).  I believe we have agreed
that printing "(none)" or some other clearly-not-an-ACL-entry string
for the second case is an improvement, even though that's a change
in behavior.  That doesn't mean that changing the other case can't
also be an improvement.  I think it'd be less confusing all around
if this instance of NULL prints like other instances of NULL.

IOW, the current definition is "NULL privileges print as an empty
string no matter what", and I don't think that serves to reduce
confusion about whether an ACL is NULL or not.  We ought to be doing
what we can to make clear that such an ACL *is* NULL, because
otherwise people won't understand how it differs from an empty ACL.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Casual Meson fixups
Next
From: Mark Wong
Date:
Subject: Re: LLVM 16 (opaque pointers)