On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> > 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.
The first example that comes to my mind is the "ICU Locale" and the "ICU Rules"
in the output of \l. There are many others.
> 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.
That's what I think too. psql output should respect "\pset null".
So it looks like we agree on that.
> 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.
Sure, it would be best to hide this implementation detail from the user.
The correct way to do that would be to fake an ACL entry like "laurenz=arwdDxt/laurenz"
if there is a NULL in the catalog, but that would add a ton of special-case
code to psql, which does not look appealing at all.
So we cannot completely hide the implementation, but perhaps "(default)" would
be less confusing than a NULL value.
If everybody agrees, I can modify the patch to do that.
Yours,
Laurenz Albe