Re: Fix output of zero privileges in psql

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Erik Wienhold <ewie(at)mailbox(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix output of zero privileges in psql
Date: 2023-10-20 19:40:11
Message-ID: CAKFQuwYinjuJO7yPjGcDfW=CPtJh_6f7pSjZa4aiCmNoRwu09Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 20, 2023 at 12:34 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > 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.
>
> As near as I can tell, doing both things (the \pset null fix and
> substituting "(none)" for empty privileges) would be an acceptable
> answer to everyone who has commented. Let's proceed with both
> patches, or combine them into one if there are merge conflicts.
>
>
I'm under the impression that removing the null representation of empty
privileges by making them (none) removes all known \d commands that output
nulls and don't obey \pset null. At least, the existing \pset null patch
doesn't purport to fix anything that would become not applicable if the
(none) patch goes in. I.e., at present they are mutually exclusive.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-10-20 19:57:04 Re: Fix output of zero privileges in psql
Previous Message Andres Freund 2023-10-20 19:40:00 Re: Remove last traces of HPPA support