On Mon, 2023-10-23 at 07:03 -0700, David G. Johnston wrote: > On Monday, October 23, 2023, Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > > > --- a/src/bin/psql/describe.c > > +++ b/src/bin/psql/describe.c > > @@ -6718,7 +6680,13 @@ static void > > printACLColumn(PQExpBuffer buf, const char *colname) > > { > > appendPQExpBuffer(buf, > > - "pg_catalog.array_to_string(%s, E'\\n') AS \"%s\"", > > + "CASE\n" > > + " WHEN %s IS NULL THEN ''\n" > > + " WHEN pg_catalog.cardinality(%s) = 0 THEN '%s'\n" > > + " ELSE pg_catalog.array_to_string(%s, E'\\n')\n" > > + "END AS \"%s\"", > > + colname, > > + colname, gettext_noop("(none)"), > > colname, gettext_noop("Access privileges")); > > } > > > > This erroneously displays NULL as empty string and subverts my changes. > > I have removed the first branch of the CASE expression. > > There is no error here, the current consensus which this patch implements is to > not change the documented “default privileges display as blank”. We are solving > the empty privileges are not distinguishable complaint by printing (none) for them.
Erik's latest patch included my changes to display NULL as NULL in psql, so that "\pset null" works as expected.
No, per the commit message, issuing an explicit \pset null is a kludge and it gets rid of the hack in favor of making the query itself produce an empty string. i.e., we choose a poor implementation to get the documented behavior and we are cleaning that up as an aside to the main fix.
Changing the behavior so that default privileges print in correspondence to the setting of \pset null is, IME, off the table for this patch. Its one and only goal is to reliably distinguish empty and default privileges. That is our extant bug.
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.