Re: Fix output of zero privileges in psql

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 15:35:03
Message-ID: CAKFQuwYjAksEqN5AqLULDhNJAnX0WxRGXCVn8tE832+KK7qK4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 23, 2023 at 7:57 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>
> 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.
>
>
I tend to prefer the argument that these views are for human consumption
and should be designed with that in mind. Allowing the user to decide
whether they prefer NULL to print as the empty string or something else
works within that framework. And the change of behavior for everyone with
a non-default \pset gets accepted under that framework as well.

I would suggest that we make the expected presence of NULL as an input
explicit:

case when spcacl is null then null
when cardinality(spcacl) = 0 then '(none)' -- so as not to confuse
it with null being printed also as an empty string
else array_to_string(spcacl, E'\\n')
end as "Access privileges"

I would offer up:

when spcacl is null then '(default)'

along with not translating (none) and (default) and thus making the data
contents of these views environment independent. But minimizing the
variance of these command's output across systems doesn't seem like a
design goal that is likely to gain consensus and is excessive when viewed
within the framework of these being only for human consumption.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2023-10-23 15:44:04 Re: trying again to get incremental backup
Previous Message Mark Wong 2023-10-23 15:27:23 Re: LLVM 16 (opaque pointers)