Re: Fix output of zero privileges in psql
От | Laurenz Albe |
---|---|
Тема | Re: Fix output of zero privileges in psql |
Дата | |
Msg-id | dd75e69caba7cb6b0a1d46503ca9f7e5818d5ea6.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
|
Список | pgsql-hackers |
On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote: > On Mon, Oct 9, 2023 at 1:29 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > On Sun, 2023-10-08 at 19:58 -0700, David G. Johnston wrote: > > > > > 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. > > It's already mentioned there, I just felt bringing the mention of ADP and > grant/revoke both invalidating the built-in default privileges closer together > would be an improvement. Ah, sorry, I misread your comment. You are right. But then, the effects of ALTER DEFAULT PRIVILEGES are discussed later in the paragraph anyway, and we don't have to repeat that here. > > > > 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. > > Calling it an implementation detail leads me to conclude the point does not > belong in the user-facing administration documentation. Again, you have a point there. However, I find that detail useful, as it explains the user-facing behavior. Anyway, I don't think it is the job of this patch to remove that pre-existing detail. > > Are you advocating for adding a mention of "\pset null" to every backslash command > > that displays privileges? That is excessive, in my opinion. > > Yes, I am. I suppose the argument that any user of those commands is expected > to have read the ddl/privileges chapter would suffice for me though. Thanks. Then let's leave it like that. > My point with the second paragraph is that we could, instead of documenting the > caveat about null printing as empty strings is to instead issue an implicit > "\pset null '<null>'" as part of these commands, and a "\pset null" afterward, > conditioned upon it not already being set to a non-empty value. IOW, the > special-casing we do today but actually do it in a way that distinguishes the > two cases instead of forcing them to be indistinguishable. -1 The whole point of this patch is to make psql behave consistently with respect to NULLs in meta-commands. Your suggestion would subvert that idea. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления:
Следующее
От: Robert HaasДата:
Сообщение: Re: Request for comment on setting binary format output per session