Re: Restoring default privileges on objects

On 8/29/23 13:27, Tom Lane wrote:
> Erik Wienhold <ewie@ewie.name> writes:
>> On 29/08/2023 18:43 CEST Stuart McGraw <smcg4191@mtneva.com> wrote:
>>> Shouldn't psql put *something* (like "(default)" or "-") in the
>>> "Access privileges" column to indicate that?  Or conversely,
>>> something (like "(none)"?) in the revoked case?
> 
>> Indeed, that's confusing.  Command \dp always prints null as empty string [1].
>> So \pset null '(null)' has no effect.
> 
> Yeah, perhaps.  The reason it so seldom comes up is that a state of
> zero privileges is extremely rare (because it's useless in practice).
> 
> That being the case, if we were to do something about this, I'd vote
> for changing the display of zero-privileges to "(none)" or something
> along that line, rather than changing the display of NULL, which
> people are accustomed to.
> 
> Fixing \dp to honor "\pset null" for this might be a reasonable
> thing to do too.  I'm actually a bit surprised that that doesn't
> work already.
> 
>             regards, tom lane

That change would still require someone using \dp to realize that
the "Access privileges" value could be either '' or NULL (I guess
that could be pointed out more obviously in the psql doc), and then
do a '\pset null' before doing \dp?  That seems a little inconvenient.

As a possible alternative, in the query that \dp sends, what about
replacing the line:

   select ...,
     pg_catalog.array_to_string(c.relacl, E'\n') as "Access privileges"
     ...

with something like:

     CASE array_length(c.relacl,1) WHEN 0 THEN '(none)' ELSE pg_catalog.array_to_string(c.relacl, E'\n') END as "Access
privileges"

I realize that removes the ability to control with pset what is
displayed, but maybe a little more foolproof for naive users like
myself?