Re: Fix output of zero privileges in psql

On Monday, October 23, 2023, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:

> On Mon, 2023-10-23 at 08:35 -0700, David G. Johnston wrote:
>

> > along with not translating (none) and (default) and thus making the data
> contents
> > of these views environment independent. But minimizing the variance of
> these command's
> > output across systems doesn't seem like a design goal that is likely to
> gain consensus
> > and is excessive when viewed within the framework of these being only
> for human consumption.
>
> I didn't understand this completely. You want default privileges
> displayed as
> "(default)", but are you for or against "\pset null" to have its normal
> effect on
> the output of backslash commands in all other cases?

I haven’t inspected other cases but to my knowledge we don’t typically
represent non-unknown things using NULL so I’m not expecting other places
to have this representation problem.

I don’t think any of our meta-command outputs should modify pset null.
Left join cases should be considered unknown, represented as NULL, and obey
the user’s setting.

I do believe that we should be against exposing, like in this case, any
internal implementation detail that encodes something (e.g., default
privileges) as NULL in the catalogs, to the user of the psql meta-commands.

I won’t argue that exposing such NULLS is wrong, just it would preferable
IME to avoid doing so. NULL means unknown or not applicable and default
privileges are neither of those things. I get why our catalogs choose such
an encoding and agree with it, and users that find the need to consult the
catalogs will need to learn such details. But we should strive for them to
be able to survive with psql meta-commands.

David J.