On 2023-11-13 21:49 +0100, Tom Lane wrote:
> Patch pushed with minor adjustments, mainly rewriting some comments.
Thanks a lot!
--
Erik
On Mon, 2023-11-13 at 15:49 -0500, Tom Lane wrote:
> Patch pushed with minor adjustments, mainly rewriting some comments.
Thank you!
Yours,
Laurenz Albe
"David G. Johnston" writes:
> On Mon, Nov 13, 2023 at 12:36 PM Laurenz Albe
> wrote:
>> On Mon, 2023-11-13 at 11:27 +0100, Erik Wienhold wrote:
>>> On 2023-11-09 20:19 +0100, Tom Lane wrote:
So, just to clarify, we're settling on your v4 from [1]?
>>> Yes from my side.
>> +1
> +0.5 for
On Mon, Nov 13, 2023 at 12:36 PM Laurenz Albe
wrote:
> On Mon, 2023-11-13 at 11:27 +0100, Erik Wienhold wrote:
> > On 2023-11-09 20:19 +0100, Tom Lane wrote:
> > > Laurenz Albe writes:
> > > > Thanks for the feedback. I'll set the patch to "ready for
> committer" then.
> > >
> > > So, just to
On Mon, 2023-11-13 at 11:27 +0100, Erik Wienhold wrote:
> On 2023-11-09 20:19 +0100, Tom Lane wrote:
> > Laurenz Albe writes:
> > > Thanks for the feedback. I'll set the patch to "ready for committer"
> > > then.
> >
> > So, just to clarify, we're settling on your v4 from [1]?
> >
> > [1]
>
On 2023-11-09 20:19 +0100, Tom Lane wrote:
> Laurenz Albe writes:
> > Thanks for the feedback. I'll set the patch to "ready for committer" then.
>
> So, just to clarify, we're settling on your v4 from [1]?
>
> [1]
>
Laurenz Albe writes:
> Thanks for the feedback. I'll set the patch to "ready for committer" then.
So, just to clarify, we're settling on your v4 from [1]?
regards, tom lane
[1]
On Thu, 2023-11-09 at 03:40 +0100, Erik Wienhold wrote:
> On 2023-11-08 13:23 +0100, Laurenz Albe wrote:
> > I wonder how to proceed with this patch. The main disagreement is
> > whether default privileges should be displayed as NULL (less invasive,
> > but more confusing for beginners) or
On 2023-11-08 13:23 +0100, Laurenz Albe wrote:
> I wonder how to proceed with this patch. The main disagreement is
> whether default privileges should be displayed as NULL (less invasive,
> but more confusing for beginners) or "(default)" (more invasive,
> but nicer for beginners).
Are there any
On Wed, 2023-11-08 at 10:56 +0530, Shubham Khanna wrote:
> I tested the Patch for the modified changes and it is working fine.
Thanks for the review!
I wonder how to proceed with this patch. The main disagreement is
whether default privileges should be displayed as NULL (less invasive,
but more
On Wed, Nov 8, 2023 at 10:46 AM Laurenz Albe wrote:
>
> On Sat, 2023-10-21 at 04:29 +0200, Erik Wienhold wrote:
> > The attached v3 of my initial patch
> > does that. It also includes Laurenz' fix to no longer ignore \pset null
> > (minus the doc changes that suggest using \pset null to
On Mon, 2023-10-23 at 22:43 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> > > I do believe that we should be against exposing, like in this case, any
> > > internal
> > > implementation detail that encodes something (e.g., default
On Monday, October 23, 2023, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> >> I do believe that we should be against exposing, like in this case, any
> internal
> >> implementation detail that encodes something (e.g., default
On Monday, October 23, 2023, Laurenz Albe wrote:
> On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> > > I didn't understand this completely. You want default privileges
> displayed as
> > > "(default)", but are you for or against "\pset null" to have its
> normal effect on
> > >
Laurenz Albe writes:
> On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
>> I do believe that we should be against exposing, like in this case, any
>> internal
>> implementation detail that encodes something (e.g., default privileges) as
>> NULL
>> in the catalogs, to the user of the
On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> > I didn't understand this completely. You want default privileges displayed
> > as
> > "(default)", but are you for or against "\pset null" to have its normal
> > effect on
> > the output of backslash commands in all other cases?
>
On Monday, October 23, 2023, Laurenz Albe wrote:
> On Mon, 2023-10-23 at 08:35 -0700, David G. Johnston wrote:
>
> > along with not translating (none) and (default) and thus making the data
> contents
> > of these views environment independent. But minimizing the variance of
> these command's
On Mon, 2023-10-23 at 08:35 -0700, David G. Johnston wrote:
> I tend to prefer the argument that these views are for human consumption and
> should
> be designed with that in mind.
True, although given the shape of ACLs, it takes a somewhat trained human to
consume the string representation.
On Mon, Oct 23, 2023 at 7:57 AM Tom Lane wrote:
>
> IOW, the current definition is "NULL privileges print as an empty
> string no matter what", and I don't think that serves to reduce
> confusion about whether an ACL is NULL or not. We ought to be doing
> what we can to make clear that such an
"David G. Johnston" writes:
> We document default privileges print as an empty string - I do not think we
> should change the definition to "default privileges print null which can be
> controlled via \pset null", and regardless of preference doing so is not a
> bug.
Well, "if it's documented
On Monday, October 23, 2023, Laurenz Albe wrote:
> On Mon, 2023-10-23 at 07:03 -0700, David G. Johnston wrote:
> > On Monday, October 23, 2023, Laurenz Albe
> wrote:
> > >
> > > --- a/src/bin/psql/describe.c
> > > +++ b/src/bin/psql/describe.c
> > > @@ -6718,7 +6680,13 @@ static void
> >
On Mon, 2023-10-23 at 07:03 -0700, David G. Johnston wrote:
> On Monday, October 23, 2023, Laurenz Albe wrote:
> >
> > --- a/src/bin/psql/describe.c
> > +++ b/src/bin/psql/describe.c
> > @@ -6718,7 +6680,13 @@ static void
> > printACLColumn(PQExpBuffer buf, const char *colname)
> > {
On Monday, October 23, 2023, Laurenz Albe wrote:
>
> --- a/src/bin/psql/describe.c
> +++ b/src/bin/psql/describe.c
> @@ -6718,7 +6680,13 @@ static void
>printACLColumn(PQExpBuffer buf, const char *colname)
>{
> appendPQExpBuffer(buf,
> -
On Sat, 2023-10-21 at 04:29 +0200, Erik Wienhold wrote:
> The attached v3 of my initial patch
> does that. It also includes Laurenz' fix to no longer ignore \pset null
> (minus the doc changes that suggest using \pset null to distinguish
> between default and empty privileges because that's no
On Fri, Oct 20, 2023 at 7:29 PM Erik Wienhold wrote:
> On 2023-10-20 22:35 +0200, David G. Johnston wrote:
> > In short, I don't want default privileges to start to obey \pset null
> when
> > it never has before and is documented as displaying the empty string. I
> do
> > want the empty string
On 2023-10-20 22:35 +0200, David G. Johnston wrote:
> Ok, I found my mis-understanding and better understand where you are all
> coming from now; I apparently had the usage of NULL flip-flopped.
>
> Taking pg_tablespace as an example. Its "spcacl" column produces NULL for
> default privileges
On 2023-10-20 08:42 +0200, Laurenz Albe wrote:
> If you want to proceed with your patch, you could send a new version.
v2 attached.
> I think it could do with an added line of documentation to the
> "Privileges" chapter, and I'd say that the regression tests should be
> in "psql.sql" (not that
On Fri, Oct 20, 2023 at 12:57 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Fri, Oct 20, 2023 at 12:34 PM Tom Lane wrote:
> >> As near as I can tell, doing both things (the \pset null fix and
> >> substituting "(none)" for empty privileges) would be an acceptable
> >> answer to
"David G. Johnston" writes:
> On Fri, Oct 20, 2023 at 12:34 PM Tom Lane wrote:
>> As near as I can tell, doing both things (the \pset null fix and
>> substituting "(none)" for empty privileges) would be an acceptable
>> answer to everyone who has commented. Let's proceed with both
>> patches,
On Fri, Oct 20, 2023 at 12:34 PM Tom Lane wrote:
> Laurenz Albe writes:
> > I am not sure how to proceed. Perhaps it would indeed be better to have
> > two competing commitfest entries. Both could be "ready for committer",
> > and the committers can decide what they prefer.
>
> As near as I
Laurenz Albe writes:
> I am not sure how to proceed. Perhaps it would indeed be better to have
> two competing commitfest entries. Both could be "ready for committer",
> and the committers can decide what they prefer.
As near as I can tell, doing both things (the \pset null fix and
substituting
On Fri, 2023-10-20 at 04:13 +0200, Erik Wienhold wrote:
> On 2023-10-17 04:05 +0200, David G. Johnston wrote:
> > Erik seems to favors (none)
>
> Yes, with a slight favor for "(none)" because it's the least disruptive
> to users who change \pset null to a non-blank string. The output of \dp
>
On 2023-10-17 04:05 +0200, David G. Johnston wrote:
> Erik seems to favors (none)
Yes, with a slight favor for "(none)" because it's the least disruptive
to users who change \pset null to a non-blank string. The output of \dp
etc. would still look the same for default privileges.
But I'm also
Laurenz Albe writes:
> On Mon, 2023-10-16 at 19:05 -0700, David G. Johnston wrote:
>> Reading both threads I'm not seeing any specific rejection of the
>> solution that we simply represent empty privileges as "(none)".
> Thanks for that summary. I prefer my version (simply display NULLs
> as
On Mon, 2023-10-16 at 19:05 -0700, David G. Johnston wrote:
> Reading both threads I'm not seeing any specific rejection of the
> solution that we simply represent empty privileges as "(none)".
>
> I see an apparent consensus that if we do continue to represent it
> as NULL that the printout
On Mon, Oct 16, 2023 at 6:19 PM Laurenz Albe
wrote:
> On Mon, 2023-10-16 at 23:51 +0200, Erik Wienhold wrote:
> > What's the process for the CommitFest now since we settled on your
> > patch? This is my first time being involved in this, so still learning.
> > I'see that you've withdrawn your
On Mon, 2023-10-16 at 23:51 +0200, Erik Wienhold wrote:
> What's the process for the CommitFest now since we settled on your
> patch? This is my first time being involved in this, so still learning.
> I'see that you've withdrawn your initial patch [1] but this thread is
> still attached to my
On 2023-10-16 17:56 +0200, Laurenz Albe write:
> David, how do you feel about this? I am wondering whether to set this patch
> "ready for committer" or not.
>
> There is Tom wondering upthread whether changing psql's behavior like that
> is too much of a compatibility break or not, but I guess
On Sat, 2023-10-14 at 02:45 +0200, Erik Wienhold wrote:
> On 2023-10-09 09:54 +0200, Laurenz Albe write:
> >
> > I tinkered a bit with your documentation. For example, the suggestion to
> > "\pset null" seemed to be in an inappropriate place. Tell me what you
> > think.
>
> +1 You're right
On 2023-10-09 22:34 +0200, David G. Johnston write:
> On Mon, Oct 9, 2023 at 12:13 PM Tom Lane wrote:
> > Yeah. There is a lot of attraction in having \pset null affect these
> > displays just like all other ones. The fact that they act differently
> > now is a wart, not something we should
On 2023-10-09 10:29 +0200, Laurenz Albe write:
> On Sun, 2023-10-08 at 19:58 -0700, David G. Johnston wrote:
> > 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
On 2023-10-09 09:54 +0200, Laurenz Albe write:
>
> I tinkered a bit with your documentation. For example, the suggestion to
> "\pset null" seemed to be in an inappropriate place. Tell me what you think.
+1 You're right to put that sentence right after the explanation of
empty privileges.
--
On Mon, 2023-10-09 at 15:13 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > The whole point of this patch is to make psql behave consistently with
> > respect to
> > NULLs in meta-commands.
>
> Yeah. There is a lot of attraction in having \pset null affect these
> displays just like all
On Mon, Oct 9, 2023 at 12:13 PM Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote:
> >> 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
>
Laurenz Albe writes:
> On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote:
>> 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 ''" as part of these commands,
On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote:
> On Mon, Oct 9, 2023 at 1:29 AM Laurenz Albe 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
On Mon, Oct 9, 2023 at 1:29 AM Laurenz Albe
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
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
On Mon, 2023-10-09 at 03:53 +0200, Erik Wienhold 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
On Sun, Oct 8, 2023 at 6:55 PM Erik Wienhold 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
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
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
On 2023-10-07 14:29 +0200, Laurenz Albe write:
> On Sat, 2023-10-07 at 05:07 +0200, Erik Wienhold wrote:
> > On 2023-10-06 22:32 +0200, Laurenz Albe write:
> > > On Sun, 2023-09-17 at 21:31 +0200, Erik Wienhold wrote:
> > > > I wrote a patch to change psql's display of zero privileges after a
> >
On Sat, 2023-10-07 at 05:07 +0200, Erik Wienhold wrote:
> On 2023-10-06 22:32 +0200, Laurenz Albe write:
> > On Sun, 2023-09-17 at 21:31 +0200, Erik Wienhold wrote:
> > > I wrote a patch to change psql's display of zero privileges after a user's
> > > reported confusion with the psql output for
On 2023-10-06 22:32 +0200, Laurenz Albe write:
> On Sun, 2023-09-17 at 21:31 +0200, Erik Wienhold wrote:
> > I wrote a patch to change psql's display of zero privileges after a user's
> > reported confusion with the psql output for zero vs. default privileges [1].
> > Admittedly, zero privileges
On Sun, 2023-09-17 at 21:31 +0200, Erik Wienhold wrote:
> I wrote a patch to change psql's display of zero privileges after a user's
> reported confusion with the psql output for zero vs. default privileges [1].
> Admittedly, zero privileges is a rare use case [2] but I think psql should not
>
On 17/09/2023 21:31 CEST Erik Wienhold wrote:
> This affects the following meta commands:
>
> \db+ \dD+ \df+ \dL+ \dl+ \dn+ \dp \dT+ \l
also \des+ and \dew+
--
Erik
[2] https://www.postgresql.org/message-id/31246.1693337238%40sss.pgh.pa.us
--
ErikFrom 16af995acb4c0e5fb5981308610a76b7e87c3358 Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Sun, 17 Sep 2023 20:54:48 +0200
Subject: [PATCH v1] Fix output of zero privileges in psql
Print "(none)" for zero privileges i
58 matches
Mail list logo
