Re: Fix output of zero privileges in psql

On 2023-10-20 22:35 +0200, David G. Johnston wrote:
> Ok, I found my mis-understanding and better understand where you are all
> coming from now; I apparently had the usage of NULL flip-flopped.
>
> Taking pg_tablespace as an example. Its "spcacl" column produces NULL for
> default privileges and '{}'::text[] for empty privileges.
>
> Thus, today:
> empty: array_to_string('{}'::text[], '\n') produces an empty string
> default: array_to_string(null, '\n') produces null which then was printed
> as a hard-coded empty string via forcibly changing \pset null
>
> I was thinking the two cases were reversed.
>
> My proposal for changing printACLColumn is thus:
>
> case when spcacl is null then ''
> when cardinality(spcacl) = 0 then '(none)'
> else array_to_string(spcacl, E'\\n')
> end as "Access privileges"
>
> In short, I don't want default privileges to start to obey \pset null when
> it never has before and is documented as displaying the empty string. I do
> want the empty string produced by empty privileges to change to (none) so
> that it no longer is indistinguishable from our choice of presentation for
> the default privilege case.
>
> Mechanically, we remove the existing \pset null for these metacommands and
> move it into the query via the added CASE expression in the ‎printACLColumn
> function.
>
> This gets rid of NULL as an output value for this column and makes the
> patch regarding \pset null discussion unnecessary. And it leaves the
> existing well-established empty string for default privileges alone (and
> changing this is what I believe Tom is against and I agree on that point).

I haven't thought off this yet. The attached v3 of my initial patch
does that. It also includes Laurenz' fix to no longer ignore \pset null
(minus the doc changes that suggest using \pset null to distinguish
between default and empty privileges because that's no longer needed).

--
Erik