Allow CURRENT_ROLE in GRANTED BY

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_USER in 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_USER in 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&amp;dt=2020-09-17%2010%3A27%3A36
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&amp;dt=2020-09-17%2011%3A17%3A08
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&amp;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]333B0203-D19B-4335-AE64-90EB0FAF46F0@enterprisedb.com 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/