From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, 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-24 06:34:42 |
Message-ID: | 1d39d9f5e2f71d6e0038a8ce833eae80c7e70921.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2023-10-23 at 22:43 -0400, Tom Lane wrote:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> > > 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.
>
> > 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.
>
> For better or worse, that *is* the backend's catalog representation,
> and I don't think that psql would be doing our users a service by
> trying to obscure the fact. They'd run into it anyway the moment
> they look at the catalogs with anything but a \d-something command.
... for example with a client like pgAdmin, which is a frequent choice
of many PostgreSQL beginners (they display empty privileges).
Yes, it is "(default)" or NULL. The former is friendlier for beginners,
the latter incurs less backward incompatibility.
I could live with either solution, but I am still leaning towards NULL.
I ran the regression tests with a patch that displays "(default)",
and I counted 22 failures, excluding the one added by my patch.
The tests can of course be fixed, but perhaps that serves as a measure
of the backward incompatibility.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Étienne BERSAC | 2023-10-24 07:12:46 | Re: RFC: Logging plan of the running query |
Previous Message | Drouvot, Bertrand | 2023-10-24 06:24:20 | Re: Synchronizing slots from primary to standby |