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)ewie(dot)name>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix output of zero privileges in psql
Date: 2023-10-09 20:34:47
Message-ID: CAKFQuwaqHy=ZD7V2sXmH3w9kpVT4f3EmsKmSwy27P2eufLhO1w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 9, 2023 at 12:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote:
> >> My point with the second paragraph is that we could, instead of
> documenting the
> >> caveat about null printing as empty strings is to instead issue an
> implicit
> >> "\pset null '<null>'" as part of these commands, and a "\pset null"
> afterward,
> >> conditioned upon it not already being set to a non-empty value. IOW,
> the
> >> special-casing we do today but actually do it in a way that
> distinguishes the
> >> two cases instead of forcing them to be indistinguishable.
>
> > -1
>
> > The whole point of this patch is to make psql behave consistently with
> respect to
> > NULLs in meta-commands. Your suggestion would subvert that idea.
>
> Yeah. There is a lot of attraction in having \pset null affect these
> displays just like all other ones. The fact that they act differently
> now is a wart, not something we should replace with a different special
> case behavior.
>
> Also, I'm fairly concerned about not changing the default behavior here.
> The fact that this behavior has stood for a couple dozen years without
> many complaints indicates that there's not all that big a problem to be
> solved. I doubt that a new default behavior will be well received,
> even if it's arguably better.
>

My position is that the default behavior should be changed such that the
distinction these reports need to make between empty privileges and default
privileges is impossible for the user to remove. I suppose the best direct
solution given that goal is for the query to simply do away with any
reliance on NULL being an indicator. Output an i18n'd "no permissions
present" line in the rare empty permissions situation and leave the empty
string for built-in default.

If the consensus is to not actually fix these views to make them
environment invariant in their accuracy then so be it. Having them obey
\pset null seems like a half-measure but it at least is an improvement over
the status quo such that users are capable of altering their system to make
the reports distinguish the two cases if they realize the need.

I do agree that my suggestion regarding the implicit \pset null, while
plausible, leaves the wart that NULL is being used to mean something
specific. Better is to just use a label for that specific thing.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-10-09 20:47:02 Re: New WAL record to detect the checkpoint redo location
Previous Message Jelte Fennema 2023-10-09 20:27:15 Re: Request for comment on setting binary format output per session