On Monday, October 23, 2023, Laurenz Albe <
laurenz.albe@cybertec.at> wrote:
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.
Both of those fall into “this null means there is no value for these (because we aren’t using icu)”. I have no qualms with leaving true nulls represented as themselves. Clean slate maybe I print “(not using icu)” there instead of null but it isn’t worth the effort to change.
>
> 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.
More generically it would be “[PUBLIC=]/???/postgres” and {OWNER}=???/postgres
It would ideally be a function call for psql and a system info function usable for anyone.
David J.