Re: Fix output of zero privileges in psql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Erik Wienhold <ewie(at)ewie(dot)name>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix output of zero privileges in psql
Date: 2023-10-23 14:57:09
Message-ID: 377395.1698073029@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Wong 2023-10-23 15:27:23 Re: LLVM 16 (opaque pointers)
Previous Message Andrew Dunstan 2023-10-23 14:39:56 Re: Casual Meson fixups