Re: Fix output of zero privileges in psql

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

On Fri, 2023-10-20 at 04:13 +0200, Erik Wienhold wrote:
> On 2023-10-17 04:05 +0200, David G. Johnston wrote:
> > Erik seems to favors (none)
>
> Yes, with a slight favor for "(none)" because it's the least disruptive
> to users who change \pset null to a non-blank string.  The output of \dp
> etc. would still look the same for default privileges.
>
> But I'm also okay with respecting \pset null because it is so simple.
> We will no longer hide the already documented null representation of
> default privileges by allowing the user to display the ACL as it is.
> And with Laurenz' patch we will also document the special case of zero
> privileges and how to distinguish it.

If you want to proceed with your patch, you could send a new version.

I think it could do with an added line of documentation to the
"Privileges" chapter, and I'd say that the regression tests should be
in "psql.sql" (not that it is very important).

I am not sure how to proceed. Perhaps it would indeed be better to have
two competing commitfest entries. Both could be "ready for committer",
and the committers can decide what they prefer.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Xiang Gao 2023-10-20 07:08:58 CRC32C Parallel Computation Optimization on ARM
Previous Message Dilip Kumar 2023-10-20 04:10:35 Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock