Re: Allow CURRENT_ROLE in GRANTED BY
> On 18 Nov 2021, at 14:42, Daniel Gustafsson wrote: > >> On 18 Nov 2021, at 14:41, Peter Eisentraut >> wrote: >> >> On 16.11.21 15:27, Daniel Gustafsson wrote: > On 16 Nov 2021, at 15:04, Daniel Gustafsson 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/
Re: Allow CURRENT_ROLE in GRANTED BY
> On 18 Nov 2021, at 14:41, Peter Eisentraut > wrote: > > On 16.11.21 15:27, Daniel Gustafsson wrote: On 16 Nov 2021, at 15:04, Daniel Gustafsson 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.
Re: Allow CURRENT_ROLE in GRANTED BY
On 16.11.21 15:27, Daniel Gustafsson wrote: On 16 Nov 2021, at 15:04, Daniel Gustafsson 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.
Re: Allow CURRENT_ROLE in GRANTED BY
> On 16 Nov 2021, at 15:04, Daniel Gustafsson 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/ granted_by_v2.diff Description: Binary data
Re: Allow CURRENT_ROLE in GRANTED BY
> On 30 Jan 2021, at 09:51, Peter Eisentraut > wrote: > > On 2020-12-30 13:43, Simon Riggs wrote: >> On Thu, 10 Dec 2020 at 18:40, Peter Eisentraut >> 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-90eb0faf4...@enterprisedb.com granted_by.diff Description: Binary data
Re: Allow CURRENT_ROLE in GRANTED BY
On 2020-12-30 13:43, Simon Riggs wrote: On Thu, 10 Dec 2020 at 18:40, Peter Eisentraut 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/
Re: Allow CURRENT_ROLE in GRANTED BY
On Thu, 10 Dec 2020 at 18:40, Peter Eisentraut 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 Riggshttp://www.EnterpriseDB.com/
Re: Allow CURRENT_ROLE in GRANTED BY
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/
From 72b1e99337b6fc9e72bcca003eb2d18351079261 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 10 Dec 2020 19:38:21 +0100
Subject: [PATCH] Allow GRANTED BY clause in normal GRANT and REVOKE statements
The SQL standard allows a GRANTED BY clause on GRANT and
REVOKE (privilege) statements that can specify CURRENT_USER or
CURRENT_ROLE. In PostgreSQL, both of these are the default behavior.
Since we already have all the parsing support for this for the
GRANT (role) statement, we might as well add basic support for this
for the privilege variant as well. This allows us to check of SQL
feature T332. In the future, perhaps more interesting things could be
done with this, too.
---
doc/src/sgml/ref/grant.sgml | 25 ++---
doc/src/sgml/ref/revoke.sgml | 13 +
src/backend/catalog/aclchk.c | 16
src/backend/catalog/sql_features.txt | 2 +-
src/backend/nodes/copyfuncs.c| 1 +
src/backend/nodes/equalfuncs.c | 1 +
src/backend/parser/gram.y| 13 -
src/include/nodes/parsenodes.h | 1 +
8 files changed, 63 insertions(+), 9 deletions(-)
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index c3db393bde..a897712de2 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -26,58 +26,71 @@
ON { [ TABLE ] table_name [,
...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
ON [ TABLE ] table_name [,
...]
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { { USAGE | SELECT | UPDATE }
[, ...] | ALL [ PRIVILEGES ] }
ON { SEQUENCE sequence_name
[, ...]
| ALL SEQUENCES IN SCHEMA schema_name [, ...] }
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [, ...] | ALL [ PRIVILEGES ] }
ON DATABASE database_name [, ...]
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON DOMAIN domain_name [, ...]
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON FOREIGN DATA WRAPPER fdw_name [, ...]
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON FOREIGN SERVER server_name [, ...]
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
ON { { FUNCTION | PROCEDURE | ROUTINE }
routine_name [ ( [ [ argmode ] [ arg_name ] arg_type [, ...] ] ) ] [, ...]
| ALL { FUNCTIONS | PROCEDURES | ROUTINES } IN SCHEMA schema_name [, ...] }
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON LANGUAGE lang_name [, ...]
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { { SELECT | UPDATE } [, ...] | ALL [ PRIVILEGES ] }
ON LARGE OBJECT loid [, ...]
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
ON SCHEMA schema_name [, ...]
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { CREATE | ALL [ PRIVILEGES ] }
ON TABLESPACE tablespace_name [, ...]
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON TYPE type_name [, ...]
TO role_specification [, ...]
[ WITH GRANT OPTION ]
+[ GRANTED BY role_specification ]
GRANT role_name [, ...] TO
role_specification [, ...]
Re: Allow CURRENT_ROLE in GRANTED BY
Peter Eisentraut 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
Re: Allow CURRENT_ROLE in GRANTED BY
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
Re: Allow CURRENT_ROLE in GRANTED BY
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 Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Allow CURRENT_ROLE in GRANTED BY
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
Re: Allow CURRENT_ROLE in GRANTED BY
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
Re: Allow CURRENT_ROLE in GRANTED BY
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
From 3dea85cf0391828e02f901ab808dad31422ee30b Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 24 Jun 2020 08:21:48 +0200
Subject: [PATCH v2] Allow CURRENT_ROLE where CURRENT_USER is accepted
In the particular case of GRANTED BY, this is specified in the SQL
standard. Since in PostgreSQL, CURRENT_ROLE is equivalent to
CURRENT_USER, and CURRENT_USER is already supported here, adding
CURRENT_ROLE is trivial. The other cases are PostgreSQL extensions,
but for the same reason it also makes sense there.
---
doc/src/sgml/ref/alter_aggregate.sgml| 2 +-
doc/src/sgml/ref/alter_collation.sgml| 2 +-
doc/src/sgml/ref/alter_conversion.sgml | 2 +-
doc/src/sgml/ref/alter_database.sgml | 2 +-
doc/src/sgml/ref/alter_domain.sgml | 2 +-
doc/src/sgml/ref/alter_event_trigger.sgml| 2 +-
doc/src/sgml/ref/alter_foreign_data_wrapper.sgml | 2 +-
doc/src/sgml/ref/alter_foreign_table.sgml| 2 +-
doc/src/sgml/ref/alter_function.sgml | 2 +-
doc/src/sgml/ref/alter_group.sgml| 1 +
doc/src/sgml/ref/alter_language.sgml | 2 +-
doc/src/sgml/ref/alter_large_object.sgml | 2 +-
doc/src/sgml/ref/alter_materialized_view.sgml| 2 +-
doc/src/sgml/ref/alter_opclass.sgml | 2 +-
doc/src/sgml/ref/alter_operator.sgml | 2 +-
doc/src/sgml/ref/alter_opfamily.sgml | 2 +-
doc/src/sgml/ref/alter_policy.sgml | 2 +-
doc/src/sgml/ref/alter_procedure.sgml| 2 +-
doc/src/sgml/ref/alter_publication.sgml | 2 +-
doc/src/sgml/ref/alter_role.sgml | 2 ++
doc/src/sgml/ref/alter_routine.sgml | 2 +-
doc/src/sgml/ref/alter_schema.sgml | 2 +-
doc/src/sgml/ref/alter_sequence.sgml | 2 +-
doc/src/sgml/ref/alter_server.sgml | 2 +-
doc/src/sgml/ref/alter_statistics.sgml | 2 +-
doc/src/sgml/ref/alter_subscription.sgml | 2 +-
doc/src/sgml/ref/alter_table.sgml| 2 +-
doc/src/sgml/ref/alter_tablespace.sgml | 2 +-
doc/src/sgml/ref/alter_tsconfig.sgml | 2 +-
doc/src/sgml/ref/alter_tsdictionary.sgml | 2 +-
doc/src/sgml/ref/alter_type.sgml | 2 +-
doc/src/sgml/ref/alter_user.sgml | 1 +
doc/src/sgml/ref/alter_user_mapping.sgml | 4 ++--
doc/src/sgml/ref/alter_view.sgml | 2 +-
doc/src/sgml/ref/create_policy.sgml | 2 +-
doc/src/sgml/ref/create_schema.sgml | 1 +
doc/src/sgml/ref/create_tablespace.sgml | 2 +-
doc/src/sgml/ref/create_user_mapping.sgml| 4 ++--
doc/src/sgml/ref/drop_owned.sgml | 2 +-
doc/src/sgml/ref/drop_user_mapping.sgml | 4 ++--
doc/src/sgml/ref/grant.sgml | 1 +
doc/src/sgml/ref/reassign_owned.sgml | 4 ++--
doc/src/sgml/ref/revoke.sgml | 1 +
src/backend/parser/gram.y| 4
44 files changed, 52 insertions(+), 41 deletions(-)
diff --git a/doc/src/sgml/ref/alter_aggregate.sgml
b/doc/src/sgml/ref/alter_aggregate.sgml
index 2ad3e0440b..95934a100f 100644
--- a/doc/src/sgml/ref/alter_aggregate.sgml
+++ b/doc/src/sgml/ref/alter_aggregate.sgml
@@ -23,7 +23,7 @@
ALTER AGGREGATE name (
aggregate_signature ) RENAME TO
new_name
ALTER AGGREGATE name (
aggregate_signature )
-OWNER TO { new_owner | CURRENT_USER
| SESSION_USER }
+OWNER TO { new_owner | CURRENT_ROLE
| CURRENT_USER | SESSION_USER }
ALTER AGGREGATE name (
aggregate_signature ) SET SCHEMA
new_schema
where aggregate_signature is:
diff --git a/doc/src/sgml/ref/alter_collation.sgml
b/doc/src/sgml/ref/alter_collation.sgml
index bee6f0dd3c..af9ff2867b 100644
--- a/doc/src/sgml/ref/alter_collation.sgml
+++ b/doc/src/sgml/ref/alter_collation.sgml
@@ -24,7 +24,7 @@
ALTER COLLATION name REFRESH VERSION
ALTER COLLATION name RENAME TO
new_name
-ALTER COLLATION name OWNER TO {
new_owner | CURRENT_USER | SESSION_USER }
+ALTER COLLATION name OWNER TO {
new_owner | CURRENT_ROLE | CURRENT_USER |
SESSION_USER }
ALTER COLL
Re: Allow CURRENT_ROLE in GRANTED BY
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 Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Allow CURRENT_ROLE in GRANTED BY
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
Re: 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
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
From f46554c2bba025b62b796748d3aa3a65fd080f7f Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 24 Jun 2020 08:21:48 +0200
Subject: [PATCH 1/2] Allow CURRENT_ROLE in GRANTED BY
This is specified in the SQL standard. Since in PostgreSQL,
CURRENT_ROLE is equivalent to CURRENT_USER, and CURRENT_USER is
already supported here, adding CURRENT_ROLE is trivial.
---
doc/src/sgml/ref/grant.sgml | 1 +
doc/src/sgml/ref/revoke.sgml | 1 +
src/backend/parser/gram.y| 4
3 files changed, 6 insertions(+)
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index bc573f7826..fe231aa30c 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -87,6 +87,7 @@
[ GROUP ] role_name
| PUBLIC
+ | CURRENT_ROLE
| CURRENT_USER
| SESSION_USER
diff --git a/doc/src/sgml/ref/revoke.sgml b/doc/src/sgml/ref/revoke.sgml
index b6bac21c57..b50f99dfe7 100644
--- a/doc/src/sgml/ref/revoke.sgml
+++ b/doc/src/sgml/ref/revoke.sgml
@@ -114,6 +114,7 @@
[ GROUP ] role_name
| PUBLIC
+ | CURRENT_ROLE
| CURRENT_USER
| SESSION_USER
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index e669d75a5a..6e6565dc26 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -14949,6 +14949,10 @@ RoleSpec: NonReservedWord
}
$$ = n;
}
+ | CURRENT_ROLE
+ {
+ $$ =
makeRoleSpec(ROLESPEC_CURRENT_USER, @1);
+ }
| CURRENT_USER
{
$$ =
makeRoleSpec(ROLESPEC_CURRENT_USER, @1);
--
2.27.0
