Обсуждение: Allow CURRENT_ROLE in GRANTED BY
I was checking some loose ends in SQL conformance, when I noticed: We support GRANT role ... GRANTED BY CURRENT_USER, but we don't support CURRENT_ROLE in that place, even though in PostgreSQL they are equivalent. Here is a trivial patch to add that. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
On 6/24/20 8:35 AM, Peter Eisentraut wrote: > I was checking some loose ends in SQL conformance, when I noticed: We > support GRANT role ... GRANTED BY CURRENT_USER, but we don't support > CURRENT_ROLE in that place, even though in PostgreSQL they are > equivalent. Here is a trivial patch to add that. The only thing that isn't dead-obvious about this patch is the commit message says "[PATCH 1/2]". What is in the other part? Assuming that's just a remnant of development, this LGTM. -- Vik Fearing
On 2020-06-24 10:12, Vik Fearing wrote: > On 6/24/20 8:35 AM, Peter Eisentraut wrote: >> I was checking some loose ends in SQL conformance, when I noticed: We >> support GRANT role ... GRANTED BY CURRENT_USER, but we don't support >> CURRENT_ROLE in that place, even though in PostgreSQL they are >> equivalent. Here is a trivial patch to add that. > > > The only thing that isn't dead-obvious about this patch is the commit > message says "[PATCH 1/2]". What is in the other part? Hehe. The second patch is some in-progress work to add the GRANTED BY clause to the regular GRANT command. More on that perhaps at a later date. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-Jun-24, Peter Eisentraut wrote: > I was checking some loose ends in SQL conformance, when I noticed: We > support GRANT role ... GRANTED BY CURRENT_USER, but we don't support > CURRENT_ROLE in that place, even though in PostgreSQL they are equivalent. > Here is a trivial patch to add that. Hmm, since this adds to RoleSpec, this change makes every place that uses that production also take CURRENT_ROLE, so we'd need to document in all those places. For example, alter_role.sgml, create_schema.sgml, etc. This also affects role_list (but maybe the docs for those are already vague enough -- eg. ALTER INDEX .. OWNED BY only says "role_name" with no further explanation, even though it does take "current_user".) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-06-24 23:08, Alvaro Herrera wrote: > On 2020-Jun-24, Peter Eisentraut wrote: > >> I was checking some loose ends in SQL conformance, when I noticed: We >> support GRANT role ... GRANTED BY CURRENT_USER, but we don't support >> CURRENT_ROLE in that place, even though in PostgreSQL they are equivalent. >> Here is a trivial patch to add that. > > Hmm, since this adds to RoleSpec, this change makes every place that > uses that production also take CURRENT_ROLE, so we'd need to document in > all those places. For example, alter_role.sgml, create_schema.sgml, > etc. Good point. Here is an updated patch that updates all the documentation places where CURRENT_USER is mentioned. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
On 2020-06-29 14:47, Peter Eisentraut wrote: > On 2020-06-24 23:08, Alvaro Herrera wrote: >> On 2020-Jun-24, Peter Eisentraut wrote: >> >>> I was checking some loose ends in SQL conformance, when I noticed: We >>> support GRANT role ... GRANTED BY CURRENT_USER, but we don't support >>> CURRENT_ROLE in that place, even though in PostgreSQL they are equivalent. >>> Here is a trivial patch to add that. >> >> Hmm, since this adds to RoleSpec, this change makes every place that >> uses that production also take CURRENT_ROLE, so we'd need to document in >> all those places. For example, alter_role.sgml, create_schema.sgml, >> etc. > > Good point. Here is an updated patch that updates all the documentation > places where CURRENT_USER is mentioned. Here is another patch that also makes comprehensive updates to the rolenames tests under src/test/modules/unsafe_tests/. I think this should now cover all the required ancillary changes. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation: tested, passed The patch applies cleanly and looks fine to me. However wouldn't it be better to just map the CURRENT_ROLE to CURRENT_USERin backend grammar? The new status of this patch is: Waiting on Author
On 2020-09-07 12:02, Asif Rehman wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation: tested, passed > > The patch applies cleanly and looks fine to me. However wouldn't it be better to just map the CURRENT_ROLE to CURRENT_USERin backend grammar? Existing code treats them differently. I think, given that the code is already written, it is good to preserve what the user wrote. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-Aug-26, Peter Eisentraut wrote: > Here is another patch that also makes comprehensive updates to the rolenames > tests under src/test/modules/unsafe_tests/. Looks good to me. You need to DROP ROLE "current_role" at the bottom of rolenames.sql, though (as well as DROP OWNED BY, I suppose.) > I think this should now cover all the required ancillary changes. \o/ -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-09-11 22:05, Alvaro Herrera wrote: > On 2020-Aug-26, Peter Eisentraut wrote: > >> Here is another patch that also makes comprehensive updates to the rolenames >> tests under src/test/modules/unsafe_tests/. > > Looks good to me. You need to DROP ROLE "current_role" at the bottom of > rolenames.sql, though (as well as DROP OWNED BY, I suppose.) > >> I think this should now cover all the required ancillary changes. > > \o/ > committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > committed A couple of buildfarm animals are reporting instability in the modified rolenames test, eg https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hoverfly&dt=2020-09-17%2010%3A27%3A36 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2020-09-17%2011%3A17%3A08 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2020-09-17%2011%3A47%3A07 regards, tom lane
On 2020-06-24 20:21, Peter Eisentraut wrote: > On 2020-06-24 10:12, Vik Fearing wrote: >> On 6/24/20 8:35 AM, Peter Eisentraut wrote: >>> I was checking some loose ends in SQL conformance, when I noticed: We >>> support GRANT role ... GRANTED BY CURRENT_USER, but we don't support >>> CURRENT_ROLE in that place, even though in PostgreSQL they are >>> equivalent. Here is a trivial patch to add that. >> >> >> The only thing that isn't dead-obvious about this patch is the commit >> message says "[PATCH 1/2]". What is in the other part? > > Hehe. The second patch is some in-progress work to add the GRANTED BY > clause to the regular GRANT command. More on that perhaps at a later date. Here is the highly anticipated and quite underwhelming second part of this patch set. -- Peter Eisentraut 2ndQuadrant, an EDB company https://www.2ndquadrant.com/
Вложения
On Thu, 10 Dec 2020 at 18:40, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 2020-06-24 20:21, Peter Eisentraut wrote: > > On 2020-06-24 10:12, Vik Fearing wrote: > >> On 6/24/20 8:35 AM, Peter Eisentraut wrote: > >>> I was checking some loose ends in SQL conformance, when I noticed: We > >>> support GRANT role ... GRANTED BY CURRENT_USER, but we don't support > >>> CURRENT_ROLE in that place, even though in PostgreSQL they are > >>> equivalent. Here is a trivial patch to add that. > >> > >> > >> The only thing that isn't dead-obvious about this patch is the commit > >> message says "[PATCH 1/2]". What is in the other part? > > > > Hehe. The second patch is some in-progress work to add the GRANTED BY > > clause to the regular GRANT command. More on that perhaps at a later date. > > Here is the highly anticipated and quite underwhelming second part of > this patch set. Looks great, but no test to confirm it works. I would suggest adding a test and committing directly since I don't see any cause for further discussion. -- Simon Riggs http://www.EnterpriseDB.com/
On 2020-12-30 13:43, Simon Riggs wrote: > On Thu, 10 Dec 2020 at 18:40, Peter Eisentraut > <peter.eisentraut@2ndquadrant.com> wrote: >> >> On 2020-06-24 20:21, Peter Eisentraut wrote: >>> On 2020-06-24 10:12, Vik Fearing wrote: >>>> On 6/24/20 8:35 AM, Peter Eisentraut wrote: >>>>> I was checking some loose ends in SQL conformance, when I noticed: We >>>>> support GRANT role ... GRANTED BY CURRENT_USER, but we don't support >>>>> CURRENT_ROLE in that place, even though in PostgreSQL they are >>>>> equivalent. Here is a trivial patch to add that. >>>> >>>> >>>> The only thing that isn't dead-obvious about this patch is the commit >>>> message says "[PATCH 1/2]". What is in the other part? >>> >>> Hehe. The second patch is some in-progress work to add the GRANTED BY >>> clause to the regular GRANT command. More on that perhaps at a later date. >> >> Here is the highly anticipated and quite underwhelming second part of >> this patch set. > > Looks great, but no test to confirm it works. I would suggest adding a > test and committing directly since I don't see any cause for further > discussion. Committed with some tests. Thanks. -- Peter Eisentraut 2ndQuadrant, an EDB company https://www.2ndquadrant.com/
> On 30 Jan 2021, at 09:51, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 2020-12-30 13:43, Simon Riggs wrote: >> On Thu, 10 Dec 2020 at 18:40, Peter Eisentraut >> <peter.eisentraut@2ndquadrant.com> wrote: >>> >>> On 2020-06-24 20:21, Peter Eisentraut wrote: >>>> On 2020-06-24 10:12, Vik Fearing wrote: >>>>> On 6/24/20 8:35 AM, Peter Eisentraut wrote: >>>>>> I was checking some loose ends in SQL conformance, when I noticed: We >>>>>> support GRANT role ... GRANTED BY CURRENT_USER, but we don't support >>>>>> CURRENT_ROLE in that place, even though in PostgreSQL they are >>>>>> equivalent. Here is a trivial patch to add that. >>>>> >>>>> >>>>> The only thing that isn't dead-obvious about this patch is the commit >>>>> message says "[PATCH 1/2]". What is in the other part? >>>> >>>> Hehe. The second patch is some in-progress work to add the GRANTED BY >>>> clause to the regular GRANT command. More on that perhaps at a later date. >>> >>> Here is the highly anticipated and quite underwhelming second part of >>> this patch set. >> Looks great, but no test to confirm it works. I would suggest adding a >> test and committing directly since I don't see any cause for further >> discussion. > > Committed with some tests. Thanks. While looking at the proposed privileges.sql test patch from Mark Dilger [0] I realized that the commit above seems to have missed the RevokeRoleStmt syntax. As per the SQL Spec it should be supported there as well AFAICT. Was this intentional or should the attached small diff be applied to fix it? -- Daniel Gustafsson https://vmware.com/ [0] 333B0203-D19B-4335-AE64-90EB0FAF46F0@enterprisedb.com
Вложения
> On 16 Nov 2021, at 15:04, Daniel Gustafsson <daniel@yesql.se> wrote: > ..or should the attached small diff be applied to fix it? Actually it shouldn't, I realized when hitting Send that it was the wrong version. The attached is the proposed diff. -- Daniel Gustafsson https://vmware.com/
Вложения
On 16.11.21 15:27, Daniel Gustafsson wrote: >> On 16 Nov 2021, at 15:04, Daniel Gustafsson <daniel@yesql.se> wrote: > >> ..or should the attached small diff be applied to fix it? > > Actually it shouldn't, I realized when hitting Send that it was the wrong > version. The attached is the proposed diff. This appears to have been an oversight.
> On 18 Nov 2021, at 14:41, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > > On 16.11.21 15:27, Daniel Gustafsson wrote: >>>> On 16 Nov 2021, at 15:04, Daniel Gustafsson <daniel@yesql.se> wrote: >>> ..or should the attached small diff be applied to fix it? >> Actually it shouldn't, I realized when hitting Send that it was the wrong >> version. The attached is the proposed diff. > > This appears to have been an oversight. Thanks for confirming, I’ll take another pass over the proposed diff in a bit.
> On 18 Nov 2021, at 14:42, Daniel Gustafsson <daniel@yesql.se> wrote: > >> On 18 Nov 2021, at 14:41, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: >> >> On 16.11.21 15:27, Daniel Gustafsson wrote: >>>>> On 16 Nov 2021, at 15:04, Daniel Gustafsson <daniel@yesql.se> wrote: >>>> ..or should the attached small diff be applied to fix it? >>> Actually it shouldn't, I realized when hitting Send that it was the wrong >>> version. The attached is the proposed diff. >> >> This appears to have been an oversight. > > Thanks for confirming, I’ll take another pass over the proposed diff in a bit. Polished a little and pushed to master with a backpatch to 14 where it was introduced. -- Daniel Gustafsson https://vmware.com/