You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After #72123 is merged, change privilege inquiry functions like has_database_privilege, has_table_privilege, and pg_has_role in pkg/sql/sem/builtins/pg_builtins.go to use the newly-added grant option information. Currently, there is a workaround where grant options are determined for a certain privilege by checking if the user holds the GRANT privilege as well.
In addition to simplifying the code, GRANT will eventually be deprecated and removed so this change is necessary for these functions to work in the future.
For this issue:
Update the comment describing the old way of looking at the GRANT privilege.
The new logic should only be used if the new cluster version is active. See an example of a version gate here.
This might require changing planner.HasPrivilege so that it accepts a boolean parameter for withGrantOption; and the implementation should call planner.CheckGrantOption.
After #72123 is merged, change privilege inquiry functions like
has_database_privilege,has_table_privilege, andpg_has_rolein pkg/sql/sem/builtins/pg_builtins.go to use the newly-addedgrant optioninformation. Currently, there is a workaround where grant options are determined for a certain privilege by checking if the user holds theGRANTprivilege as well.In addition to simplifying the code, GRANT will eventually be deprecated and removed so this change is necessary for these functions to work in the future.
For this issue:
runSinglePrivilegeCheckso it doesn't look at the GRANT privilege directly.planner.HasPrivilegeso that it accepts a boolean parameter forwithGrantOption; and the implementation should callplanner.CheckGrantOption.See #72512 (comment) for more context
Epic CRDB-2587