On Monday, October 23, 2023, Laurenz Albe <laurenz.a...@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.
