Re: Fix output of zero privileges in psql

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Erik Wienhold <ewie(at)ewie(dot)name>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix output of zero privileges in psql
Date: 2023-10-09 08:29:07
Message-ID: 29255fb47aa829fcd7cc8c584eb8ef041edd2c7d.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2023-10-08 at 19:58 -0700, David G. Johnston wrote:
> For us, I would suggest the following wording:
>
> In addition to the situation of printing all acl items, the Access and Column
> privileges columns report two other situations specially.  In the rare case
> where all privileges for an object have been explicitly removed, including
> from the owner and PUBLIC, (i.e., has empty privileges) these columns will
> display NULL.  The other case is where the built-in default privileges are
> in effect, in which case these columns will display the empty string.
> (Note that by default psql will print NULL as an empty string, so in order
> to visually distinguish these two cases you will need to issue the \pset null
> meta-command and choose some other string to print for NULLs).  Built-in
> default privileges include all privileges for the owner, as well as those
> granted to PUBLIC per for relevant object types as described above.

That doesn't look like an improvement over the latest patches to me.

> The built-in default privileges are only in effect if the object has not been
> the target of a GRANT or REVOKE and also has not had its default privileges
> modified using ALTER DEFAULT PRIVILEGES. (???: if it is possible to revert
> back to the state of built-in privileges that would need to be described here.)

I don't think that we need to mention ALTER DEFAULT PRIVILEGES there. If
the default privileges have been altered, the ACL will not be stored as
NULL in the catalogs.

> The above removes the parenthetical regarding null in the catalogs, this is
> intentional as it seems that the goal here is to use psql instead of the
> catalogs and adding its use of null being printed as the empty string just
> seems likely to add confusion.

To me, mentioning the default privileges are stored as NULLs in the catalogs
is not an invitation to view the privileges with catalog queries, but
information about implementation details that explains why default privileges
are displayed the way they are.

> We probably should add the two terms to the glossary:
>
> empty privileges: all privileges explicitly revoked from the owner and PUBLIC
> (where applicable), and none otherwise granted.
>
> built-in default privileges: owner having all privileges and no privileges
> granted or removed via ALTER DEFAULT PRIVILEGES

"Empty privileges" are too unimportant to warrant an index entry.

I can see the value of an index entry

<indexterm>
<primary>privilege</primary>
<secondary>default</secondary>
</indexterm>

Done in the attached v5 of the patch, even though this is not really
the business of this patch.

> > > Perhaps it would also be good to mention this in the psql documentation.
>
> We've chosen a poor default and I'd rather inform the user of specific meta-commands
> to be wary of this poor default and change it at the point they will be learning
> about the meta-commands adversely affected.
>
> That said, I'd be willing to document that these commands, because they are affected
> by empty string versus null, require a non-empty-string value for \pset null and will
> choose the string '<null>' for the duration of the meta-command's execution if the
> user's setting is incompatible.

I am not certain I understood you correctly.
Are you advocating for adding a mention of "\pset null" to every backslash command
that displays privileges? That is excessive, in my opinion.

Yours,
Laurenz Albe

Attachment Content-Type Size
v5-0001-psql-honor-pset-null-in-backslash-commands.patch text/x-patch 13.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2023-10-09 08:38:54 Re: Where can I find the doxyfile?
Previous Message David Rowley 2023-10-09 08:17:00 Re: Making aggregate deserialization (and WAL receive) functions slightly faster