Re: Restoring default privileges on objects - Mailing list pgsql-general

From Erik Wienhold
Subject Re: Restoring default privileges on objects
Date
Msg-id 1200260311.340593.1693357154329@office.mailbox.org
Whole thread Raw
In response to Re: Restoring default privileges on objects  (Stuart McGraw <smcg4191@mtneva.com>)
List pgsql-general
> On 29/08/2023 22:44 CEST Stuart McGraw <smcg4191@mtneva.com> wrote:
>
> 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.

Right.

> 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
"Accessprivileges"
 
>
> I realize that removes the ability to control with pset what is
> displayed, but maybe a little more foolproof for naive users like
> myself?

I think hardcoding '(none)' is what Tom meant (at least how I read it).  Also
'(none)' should probably be localizable like the table header.

The \pset change would be separate.

--
Erik



pgsql-general by date:

Previous
From: Erik Wienhold
Date:
Subject: createuser unexpectedly creates superuser with createdb and createrole
Next
From: Laurenz Albe
Date:
Subject: Re: createuser unexpectedly creates superuser with createdb and createrole