Re: Fix output of zero privileges in psql - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Fix output of zero privileges in psql
Date
Msg-id CAKFQuwbWt6pvSFERENDh-v8bsahgSd1NDfxsRfFT4g_MNDu+ZQ@mail.gmail.com
Whole thread Raw
In response to Re: Fix output of zero privileges in psql  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Fix output of zero privileges in psql
Re: Fix output of zero privileges in psql
List pgsql-hackers
On Mon, Oct 16, 2023 at 6:19 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Mon, 2023-10-16 at 23:51 +0200, Erik Wienhold wrote:
> What's the process for the CommitFest now since we settled on your
> patch?  This is my first time being involved in this, so still learning.
> I'see that you've withdrawn your initial patch [1] but this thread is
> still attached to my patch [2].  Should I edit my CF entry (or withdraw
> it) and you reactivate yours?

I don't think it makes sense to have two competing commitfest entries,
and we should leave it on this thread.  If you are concerned about
authorship, we could both be mentioned as co-authors, if the patch ever
gets committed.

I'd still like to wait for feedback from David before I change anything.


Reading both threads I'm not seeing any specific rejection of the solution that we simply represent empty privileges as "(none)".

I see an apparent consensus that if we do continue to represent it as NULL that the printout should respect \pset null.

Tom commented in favor of (none) on the other thread with some commentary regarding how extremely rare it is; then turns around and is "fairly concerned" about changing the current blank presentation of its value which is going to happen for some people regardless of which approach is chosen. (idk...maybe in favor of (none))

Peter's comment doesn't strike me as recognizing that (none) is even an option on the table...(n/a)

Stuart, the original user complainant, seems to favor (none)

Erik seems to favors (none)

I favor (none)

It's unclear to me whether you Laurenz are against (none) or just trying to go with the group consensus that doesn't actually seem to be against (none).

I'm in favor of iterating on v1 on this thread (haven't read it yet) and presenting it as the proposed solution.  If that ends up getting shot down we can revive v5 (still need to review as well).

We should probably post on that thread that this one exists and post a link to it.

David J.

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: run pgindent on a regular basis / scripted manner
Next
From: Tom Lane
Date:
Subject: Re: Add support for AT LOCAL