Re: Fix output of zero privileges in psql

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Fix output of zero privileges in psql
Дата
Msg-id 29255fb47aa829fcd7cc8c584eb8ef041edd2c7d.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Fix output of zero privileges in psql  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Fix output of zero privileges in psql  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Fix output of zero privileges in psql  (Erik Wienhold <ewie@ewie.name>)
Список pgsql-hackers
On Sun, 2023-10-08 at 19:58 -0700, David G. Johnston wrote:
> 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.

That doesn't look like an improvement over the latest patches to me.

> 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.)

I don't think that we need to mention ALTER DEFAULT PRIVILEGES there.  If
the default privileges have been altered, the ACL will not be stored as
NULL in the catalogs.

> 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.

To me, mentioning the default privileges are stored as NULLs in the catalogs
is not an invitation to view the privileges with catalog queries, but
information about implementation details that explains why default privileges
are displayed the way they are.

> 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

"Empty privileges" are too unimportant to warrant an index entry.

I can see the value of an index entry

<indexterm>
 <primary>privilege</primary>
 <secondary>default</secondary>
</indexterm>

Done in the attached v5 of the patch, even though this is not really
the business of this patch.

> > > Perhaps it would also be good to mention this in the psql documentation.
>
> 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.

I am not certain I understood you correctly.
Are you advocating for adding a mention of "\pset null" to every backslash command
that displays privileges?  That is excessive, in my opinion.

Yours,
Laurenz Albe

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Making aggregate deserialization (and WAL receive) functions slightly faster
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: Where can I find the doxyfile?