From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | 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-09 18:56:29 |
Message-ID: | dd75e69caba7cb6b0a1d46503ca9f7e5818d5ea6.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)albe(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-10-09 18:59:53 | Re: Request for comment on setting binary format output per session |
Previous Message | Andrey Borodin | 2023-10-09 18:46:06 | Re: UUID v7 |