Re: Fix output of zero privileges in psql - Mailing list pgsql-hackers
| From | David G. Johnston |
|---|---|
| Subject | Re: Fix output of zero privileges in psql |
| Date | |
| Msg-id | CAKFQuwYB0DAteJacZhX+PYaUEjB267gQtP6SBUa2bjDNwDpd1Q@mail.gmail.com Whole thread Raw |
| In response to | Re: Fix output of zero privileges in psql (Erik Wienhold <ewie@ewie.name>) |
| Responses |
Re: Fix output of zero privileges in psql
|
| List | pgsql-hackers |
On Sun, Oct 8, 2023 at 6:55 PM Erik Wienhold <ewie@ewie.name> wrote:
On 2023-10-08 06:14 +0200, Laurenz Albe write:
> On Sat, 2023-10-07 at 20:41 +0200, Erik Wienhold wrote:
> > > If you are happy enough with my patch, shall we mark it as ready for
> > > committer?
> >
> > I amended your patch to also document the effect of \pset null in this
> > case. See the attached v2.
>
> +1
>
> If you mention in ddl.sgml that you can use "\pset null" to distinguish
> default from no privileges, you should mention that this only works with
> psql. Many people out there don't use psql.
I don't think this is necessary because that section in ddl.sgml is
already about psql and \dp.
I agree that we are simply detailing how psql makes this information available to the reader and leave users of other clients on their own to figure out their own methods - which many clients probably have handled for them anyway.
For us, I would suggest the following wording:
In addition to the situation of printing all acl items, the Access and Column privileges columns report two other situations specially. In the rare case where all privileges for an object have been explicitly removed, including from the owner and PUBLIC, (i.e., has empty privileges) these columns will display NULL. The other case is where the built-in default privileges are in effect, in which case these columns will display the empty string. (Note that by default psql will print NULL as an empty string, so in order to visually distinguish these two cases you will need to issue the \pset null meta-command and choose some other string to print for NULLs). Built-in default privileges include all privileges for the owner, as well as those granted to PUBLIC per for relevant object types as described above. The built-in default privileges are only in effect if the object has not been the target of a GRANT or REVOKE and also has not had its default privileges modified using ALTER DEFAULT PRIVILEGES. (???: if it is possible to revert back to the state of built-in privileges that would need to be described here.)
The above removes the parenthetical regarding null in the catalogs, this is intentional as it seems that the goal here is to use psql instead of the catalogs and adding its use of null being printed as the empty string just seems likely to add confusion.
> Also, I'm not sure if "zero privileges" will be readily understood by
> everybody. Perhaps "no privileges at all, even for the object owner"
> would be a better wording.
Changed in v3 to "empty privileges" with an explanation that this means
"no privileges at all, even for the object owner".
+1
We probably should add the two terms to the glossary:
empty privileges: all privileges explicitly revoked from the owner and PUBLIC (where applicable), and none otherwise granted.
built-in default privileges: owner having all privileges and no privileges granted or removed via ALTER DEFAULT PRIVILEGES
> Perhaps it would also be good to mention this in the psql documentation.
Just once under \pset null with a reference to section 5.7? Something
like "This is also useful for distinguishing default privileges from
empty privileges as explained in Section 5.7."
Or instead under every command affected by this change? \dp and \ddp
already have such a reference ("The meaning of the privilege display is
explained in Section 5.7.")
I prefer the first one because it's less effort ;) Also done in v3.
We've chosen a poor default and I'd rather inform the user of specific meta-commands to be wary of this poor default and change it at the point they will be learning about the meta-commands adversely affected.
That said, I'd be willing to document that these commands, because they are affected by empty string versus null, require a non-empty-string value for \pset null and will choose the string '<null>' for the duration of the meta-command's execution if the user's setting is incompatible.
David J.
pgsql-hackers by date: