I need to check if a set of privileges has a specific privilege for several times. But we only have raw slices []PrivilegeType, which means I either write a loop or a function on my own - too verbose. The privileges verification package, however, is using bitmask(AllPrivMask) to do that - not consistent.
It is very annoying that TiDB str, ok := Priv2UserCol[v] followed by three lines of if !ok { return "invalid priv" }. We should use the global set, e.g.AllGlobalPrivs, to check if it is a valid privilege, then just use String() to get a string.
After checking code in parser/mysql, I decided to do some small refactors to:
Hide direct usage of all maps like AllXXXPrivs, or Priv2UserCol by invoking methods. Possibly replace maps with switch.
Make one bitset type for collections of privileges. Then executor and privileges packages in TiDB could share one type.
The logic will be more self-contained. And TiDB will get a consistent API and a less verbose solution for my fix on tidb#22703. However, the refactor will break the compilation of TiDB.
So this PR will only try to prepare for removing all direct accesses to maps. The refactor should be possible to be done in several PRs without breaking others' PR merging.
What problem does this PR solve?
While fixing https://github.com/pingcap/tidb/issues/22703, I noticed two problems:
[]PrivilegeType
, which means I either write a loop or a function on my own - too verbose. The privileges verification package, however, is using bitmask(AllPrivMask) to do that - not consistent.str, ok := Priv2UserCol[v]
followed by three lines ofif !ok { return "invalid priv" }
. We should use the global set, e.g.AllGlobalPrivs
, to check if it is a valid privilege, then just useString()
to get a string.After checking code in
parser/mysql
, I decided to do some small refactors to:AllXXXPrivs
, orPriv2UserCol
by invoking methods. Possibly replace maps with switch.The logic will be more self-contained. And TiDB will get a consistent API and a less verbose solution for my fix on tidb#22703. However, the refactor will break the compilation of TiDB.
So this PR will only try to prepare for removing all direct accesses to maps. The refactor should be possible to be done in several PRs without breaking others' PR merging.
Check List
Tests
Code changes