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