From 5c2a9c0d1d615ae1e55a0d5ff31824ca684f15a1 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Wed, 18 Mar 2026 14:04:43 +0800 Subject: [PATCH 1/9] Add temp.md --- temp.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 temp.md diff --git a/temp.md b/temp.md new file mode 100644 index 0000000000000..af27ff4986a7b --- /dev/null +++ b/temp.md @@ -0,0 +1 @@ +This is a test file. \ No newline at end of file From f52c22b373fd6247f97f7ea21ec4b22895a0e35f Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Wed, 18 Mar 2026 14:04:47 +0800 Subject: [PATCH 2/9] Delete temp.md --- temp.md | 1 - 1 file changed, 1 deletion(-) delete mode 100644 temp.md diff --git a/temp.md b/temp.md deleted file mode 100644 index af27ff4986a7b..0000000000000 --- a/temp.md +++ /dev/null @@ -1 +0,0 @@ -This is a test file. \ No newline at end of file From 207b09d030164b565d47bc1f3221d167b43deb6f Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Wed, 18 Mar 2026 06:06:06 +0000 Subject: [PATCH 3/9] Auto-sync: Update English docs from Chinese PR Synced from: https://github.com/pingcap/docs-cn/pull/21437 Target PR: https://github.com/pingcap/docs/pull/22574 AI Provider: gemini Co-authored-by: github-actions[bot] --- TOC.md | 1 + column-privilege-management.md | 169 ++++++++++++++++++ mysql-compatibility.md | 3 +- privilege-management.md | 1 + .../sql-statement-grant-privileges.md | 2 +- .../sql-statement-revoke-privileges.md | 1 + 6 files changed, 174 insertions(+), 3 deletions(-) create mode 100644 column-privilege-management.md diff --git a/TOC.md b/TOC.md index f880953edda66..d53dacf332efc 100644 --- a/TOC.md +++ b/TOC.md @@ -627,6 +627,7 @@ - Privileges - [Security Compatibility with MySQL](/security-compatibility-with-mysql.md) - [Privilege Management](/privilege-management.md) + - [Column Privilege Management](/column-privilege-management.md) - [User Account Management](/user-account-management.md) - [TiDB Password Management](/password-management.md) - [Role-Based Access Control](/role-based-access-control.md) diff --git a/column-privilege-management.md b/column-privilege-management.md new file mode 100644 index 0000000000000..5d5f2037f9dec --- /dev/null +++ b/column-privilege-management.md @@ -0,0 +1,169 @@ +```markdown +title: Column-Level Privilege Management +summary: TiDB supports a MySQL-compatible column-level privilege management mechanism, allowing you to grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns of a table using `GRANT` or `REVOKE`, thus achieving finer-grained access control. +--- + +# Column-Level Privilege Management + +Starting from version v8.5.6, TiDB supports a MySQL-compatible column-level privilege management mechanism. With column-level privileges, you can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns of a table, achieving finer-grained data access control. + +> **Note:** +> +> Although MySQL syntax allows column-level specification like `REFERENCES(col_name)`, `REFERENCES` itself is a database/table-level privilege used for foreign key-related permission checks. Therefore, column-level `REFERENCES` does not actually take effect in MySQL. TiDB's behavior is consistent with MySQL. + +## Syntax + +Granting and revoking column-level privileges are similar to table-level privileges, with the following differences: + +- The column name list is placed after the **privilege type**, not after the **table name**. +- Multiple column names are separated by commas (`,`). + +```sql +GRANT priv_type(col_name [, col_name] ...) [, priv_type(col_name [, col_name] ...)] ... + ON db_name.tbl_name + TO 'user'@'host'; + +REVOKE priv_type(col_name [, col_name] ...) [, priv_type(col_name [, col_name] ...)] ... + ON db_name.tbl_name + FROM 'user'@'host'; +``` + +Where: + +* `priv_type` supports `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES`. +* The `ON` clause requires specifying the specific table, for example, `test.tbl`. +* A single `GRANT` or `REVOKE` statement can include multiple privilege items, and each privilege item can specify its own list of column names. + +For example, the following statement grants `SELECT` privileges on `col1` and `col2` and `UPDATE` privilege on `col3` to the user: + +```sql +GRANT SELECT(col1, col2), UPDATE(col3) ON test.tbl TO 'user'@'host'; +``` + +## Granting Column-Level Privileges + +The following example grants the `SELECT` privilege on `col1` and `col2` of table `test.tbl` to user `newuser`, and grants the `UPDATE` privilege on `col3` to the same user: + +```sql +CREATE DATABASE IF NOT EXISTS test; +USE test; + +DROP TABLE IF EXISTS tbl; +CREATE TABLE tbl (col1 INT, col2 INT, col3 INT); + +DROP USER IF EXISTS 'newuser'@'%'; +CREATE USER 'newuser'@'%'; + +GRANT SELECT(col1, col2), UPDATE(col3) ON test.tbl TO 'newuser'@'%'; +SHOW GRANTS FOR 'newuser'@'%'; +``` + +``` ++---------------------------------------------------------------------+ +| Grants for newuser@% | ++---------------------------------------------------------------------+ +| GRANT USAGE ON *.* TO 'newuser'@'%' | +| GRANT SELECT(col1, col2), UPDATE(col3) ON test.tbl TO 'newuser'@'%' | ++---------------------------------------------------------------------+ +``` + +In addition to using `SHOW GRANTS`, you can also view column-level privilege information by querying [`INFORMATION_SCHEMA.COLUMN_PRIVILEGES`](/information-schema/information-schema-columns.md). + +## Revoking Column-Level Privileges + +The following example revokes the `SELECT` privilege on column `col2` from user `newuser`: + +```sql +REVOKE SELECT(col2) ON test.tbl FROM 'newuser'@'%'; +SHOW GRANTS FOR 'newuser'@'%'; +``` + +``` ++---------------------------------------------------------------+ +| Grants for newuser@% | ++---------------------------------------------------------------+ +| GRANT USAGE ON *.* TO 'newuser'@'%' | +| GRANT SELECT(col1), UPDATE(col3) ON test.tbl TO 'newuser'@'%' | ++---------------------------------------------------------------+ +``` + +## Column-Level Privilege Access Control Example + +After granting or revoking column-level privileges, TiDB performs privilege checks on columns referenced in SQL statements. For example: + +* `SELECT` statements: `SELECT` column privileges affect columns referenced in the `SELECT` list as well as `WHERE`, `ORDER BY`, and other clauses. +* `UPDATE` statements: Columns being updated in the `SET` clause require `UPDATE` column privileges. Columns read in expressions or conditions usually also require `SELECT` column privileges. +* `INSERT` statements: Columns being written to require `INSERT` column privileges. `INSERT INTO t VALUES (...)` is equivalent to writing to all columns. + +In the following example, user `newuser` can only query `col1` and update `col3`: + +```sql +-- Execute as newuser +SELECT col1 FROM tbl; +SELECT * FROM tbl; -- Error (missing SELECT column privilege for col2, col3) + +UPDATE tbl SET col3 = 1; +UPDATE tbl SET col1 = 2; -- Error (missing UPDATE column privilege for col1) + +UPDATE tbl SET col3 = col1; +UPDATE tbl SET col3 = col3 + 1; -- Error (missing SELECT column privilege for col3) +UPDATE tbl SET col3 = col1 WHERE col1 > 0; +``` + +## Compatibility Differences with MySQL + +TiDB's column-level privileges are generally compatible with MySQL. However, there are differences in the following scenarios: +| Scenario | TiDB | MySQL | +| :--------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Revoking column-level privileges not granted to a user | `REVOKE` executes successfully. | `REVOKE` throws an error. | +| Execution order of column pruning and `SELECT` privilege check | `SELECT` column privileges are checked first, then column pruning is performed. For example: executing `SELECT a FROM (SELECT a, b FROM t) s` requires `SELECT` column privileges for both `t.a` and `t.b`. | Column pruning is performed first, then `SELECT` column privileges are checked. For example: executing `SELECT a FROM (SELECT a, b FROM t) s` only requires `SELECT` column privilege for `t.a`. | + +### Column Pruning and Privilege Checks in View Scenarios + +When performing `SELECT` privilege checks on views, MySQL first prunes columns in the view's internal query and then checks the column privileges of the internal tables, making the checks relatively lenient in some scenarios. TiDB does not perform column pruning before privilege checks, so additional column privileges might be required. + +```sql +-- Prepare the environment by logging in as root +DROP USER IF EXISTS 'u'@'%'; +CREATE USER 'u'@'%'; + +DROP TABLE IF EXISTS t; +CREATE TABLE t (a INT, b INT, c INT, d INT); + +DROP VIEW IF EXISTS v; +CREATE SQL SECURITY INVOKER VIEW v AS SELECT a, b FROM t WHERE c = 0 ORDER BY d; + +GRANT SELECT ON v TO 'u'@'%'; + +-- Log in as u +SELECT a FROM v; +-- MySQL: Error, missing access privileges for t.a, t.c, t.d +-- TiDB: Error, missing access privileges for t.a, t.b, t.c, t.d + +-- Log in as root +GRANT SELECT(a, c, d) ON t TO 'u'@'%'; + +-- Log in as u +SELECT a FROM v; +-- MySQL: Success (internal query is pruned to `SELECT a FROM t WHERE c = 0 ORDER BY d`) +-- TiDB: Error, missing access privileges for t.b + +SELECT * FROM v; +-- MySQL: Error, missing access privileges for t.b +-- TiDB: Error, missing access privileges for t.b + +-- Log in as root +GRANT SELECT(b) ON t TO 'u'@'%'; + +-- Log in as u +SELECT * FROM v; +-- MySQL: Success +-- TiDB: Success +``` + +## See Also + +* [Privilege Management](/privilege-management.md) +* [`GRANT `](/sql-statements/sql-statement-grant-privileges.md) +* [`REVOKE `](/sql-statements/sql-statement-revoke-privileges.md) +``` \ No newline at end of file diff --git a/mysql-compatibility.md b/mysql-compatibility.md index bea14fd7213dd..7ca47c028cd10 100644 --- a/mysql-compatibility.md +++ b/mysql-compatibility.md @@ -51,11 +51,10 @@ You can try out TiDB features on [TiDB Playground](https://play.tidbcloud.com/?u > Currently, only {{{ .starter }}} and {{{ .essential }}} clusters in certain AWS regions support [`FULLTEXT` syntax and indexes](https://docs.pingcap.com/tidbcloud/vector-search-full-text-search-sql). TiDB Self-Managed and TiDB Cloud Dedicated support parsing the `FULLTEXT` syntax but do not support using the `FULLTEXT` indexes. + `SPATIAL` (also known as `GIS`/`GEOMETRY`) functions, data types and indexes [#6347](https://github.com/pingcap/tidb/issues/6347) -+ Character sets other than `ascii`, `latin1`, `binary`, `utf8`, `utf8mb4`, and `gbk`. ++ Character sets other than `ascii`, `latin1`, `binary`, `utf8`, `utf8mb4`, `gbk`, and `gb18030`. + Optimizer trace + XML Functions + X-Protocol [#1109](https://github.com/pingcap/tidb/issues/1109) -+ Column-level privileges [#9766](https://github.com/pingcap/tidb/issues/9766) + `XA` syntax (TiDB uses a two-phase commit internally, but this is not exposed via an SQL interface) + `CREATE TABLE tblName AS SELECT stmt` syntax [#4754](https://github.com/pingcap/tidb/issues/4754) + `CHECK TABLE` syntax [#4673](https://github.com/pingcap/tidb/issues/4673) diff --git a/privilege-management.md b/privilege-management.md index 3d789cc54ec23..c7c8a8fe0256a 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -29,6 +29,7 @@ Use the following statement to grant the `xxx` user all privileges on all databa ```sql GRANT ALL PRIVILEGES ON *.* TO 'xxx'@'%'; ``` +From v8.5.6, TiDB supports the MySQL-compatible column-level privilege management mechanism. You can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges for specific columns at the table level. For more information, see [Column Privilege Management](/column-privilege-management.md). By default, [`GRANT`](/sql-statements/sql-statement-grant-privileges.md) statements will return an error if the user specified does not exist. This behavior depends on if the [SQL mode](/system-variables.md#sql_mode) `NO_AUTO_CREATE_USER` is specified: diff --git a/sql-statements/sql-statement-grant-privileges.md b/sql-statements/sql-statement-grant-privileges.md index 83b14b0f76581..34415b25b8ffa 100644 --- a/sql-statements/sql-statement-grant-privileges.md +++ b/sql-statements/sql-statement-grant-privileges.md @@ -82,7 +82,7 @@ mysql> SHOW GRANTS FOR 'newuser'; ## MySQL compatibility * Similar to MySQL, the `USAGE` privilege denotes the ability to log into a TiDB server. -* Column level privileges are not currently supported. +* Starting from v8.5.6, TiDB supports a MySQL-compatible column-level privilege management mechanism. You can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns at the table level. For more information, see [Column-level privilege management](/column-privilege-management.md). * Similar to MySQL, when the `NO_AUTO_CREATE_USER` sql mode is not present, the `GRANT` statement will automatically create a new user with an empty password when a user does not exist. Removing this sql-mode (it is enabled by default) presents a security risk. * In TiDB, after the `GRANT ` statement is executed successfully, the execution result takes effect immediately on the current connection. Whereas [in MySQL, for some privileges, the execution results take effect only on subsequent connections](https://dev.mysql.com/doc/refman/8.0/en/privilege-changes.html). See [TiDB #39356](https://github.com/pingcap/tidb/issues/39356) for details. diff --git a/sql-statements/sql-statement-revoke-privileges.md b/sql-statements/sql-statement-revoke-privileges.md index 9fb6f6681e9f5..ccd419e006d70 100644 --- a/sql-statements/sql-statement-revoke-privileges.md +++ b/sql-statements/sql-statement-revoke-privileges.md @@ -6,6 +6,7 @@ summary: An overview of the usage of REVOKE for the TiDB database. # `REVOKE ` This statement removes privileges from an existing user. Executing this statement requires the `GRANT OPTION` privilege and all privileges you revoke. +Starting from TiDB v8.5.6 and subsequent 8.5.x versions, TiDB supports the MySQL-compatible column-level privilege management mechanism. You can specify a list of column names in `REVOKE`, for example `REVOKE SELECT(col2) ON test.tbl FROM 'user'@'host';`. For more information, see [Column Privilege Management](/column-privilege-management.md). ## Synopsis From 6360553abe08e3cb344f74d4384f4e528d0a6381 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Wed, 18 Mar 2026 14:08:36 +0800 Subject: [PATCH 4/9] Update column-privilege-management.md --- column-privilege-management.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/column-privilege-management.md b/column-privilege-management.md index 5d5f2037f9dec..bc26379a607f6 100644 --- a/column-privilege-management.md +++ b/column-privilege-management.md @@ -1,4 +1,4 @@ -```markdown +`` title: Column-Level Privilege Management summary: TiDB supports a MySQL-compatible column-level privilege management mechanism, allowing you to grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns of a table using `GRANT` or `REVOKE`, thus achieving finer-grained access control. --- @@ -40,7 +40,7 @@ For example, the following statement grants `SELECT` privileges on `col1` and `c GRANT SELECT(col1, col2), UPDATE(col3) ON test.tbl TO 'user'@'host'; ``` -## Granting Column-Level Privileges +## Grant column-level privileges The following example grants the `SELECT` privilege on `col1` and `col2` of table `test.tbl` to user `newuser`, and grants the `UPDATE` privilege on `col3` to the same user: @@ -69,7 +69,7 @@ SHOW GRANTS FOR 'newuser'@'%'; In addition to using `SHOW GRANTS`, you can also view column-level privilege information by querying [`INFORMATION_SCHEMA.COLUMN_PRIVILEGES`](/information-schema/information-schema-columns.md). -## Revoking Column-Level Privileges +## Revoke column-level privileges The following example revokes the `SELECT` privilege on column `col2` from user `newuser`: @@ -87,7 +87,7 @@ SHOW GRANTS FOR 'newuser'@'%'; +---------------------------------------------------------------+ ``` -## Column-Level Privilege Access Control Example +## Column-level privilege access control example After granting or revoking column-level privileges, TiDB performs privilege checks on columns referenced in SQL statements. For example: @@ -110,7 +110,7 @@ UPDATE tbl SET col3 = col3 + 1; -- Error (missing SELECT column privilege for co UPDATE tbl SET col3 = col1 WHERE col1 > 0; ``` -## Compatibility Differences with MySQL +## Compatibility differences with MySQL TiDB's column-level privileges are generally compatible with MySQL. However, there are differences in the following scenarios: | Scenario | TiDB | MySQL | @@ -118,7 +118,7 @@ TiDB's column-level privileges are generally compatible with MySQL. However, the | Revoking column-level privileges not granted to a user | `REVOKE` executes successfully. | `REVOKE` throws an error. | | Execution order of column pruning and `SELECT` privilege check | `SELECT` column privileges are checked first, then column pruning is performed. For example: executing `SELECT a FROM (SELECT a, b FROM t) s` requires `SELECT` column privileges for both `t.a` and `t.b`. | Column pruning is performed first, then `SELECT` column privileges are checked. For example: executing `SELECT a FROM (SELECT a, b FROM t) s` only requires `SELECT` column privilege for `t.a`. | -### Column Pruning and Privilege Checks in View Scenarios +### Column pruning and privilege checks in view scenarios When performing `SELECT` privilege checks on views, MySQL first prunes columns in the view's internal query and then checks the column privileges of the internal tables, making the checks relatively lenient in some scenarios. TiDB does not perform column pruning before privilege checks, so additional column privileges might be required. @@ -161,9 +161,9 @@ SELECT * FROM v; -- TiDB: Success ``` -## See Also +## See also * [Privilege Management](/privilege-management.md) * [`GRANT `](/sql-statements/sql-statement-grant-privileges.md) * [`REVOKE `](/sql-statements/sql-statement-revoke-privileges.md) -``` \ No newline at end of file +``` From dcc92155eab9f85bf65570429c6eb02995a69478 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Wed, 18 Mar 2026 14:26:33 +0800 Subject: [PATCH 5/9] Apply suggestions from code review --- TOC.md | 2 +- column-privilege-management.md | 16 ++++++++++------ mysql-compatibility.md | 2 +- privilege-management.md | 2 +- sql-statements/sql-statement-grant-privileges.md | 2 +- .../sql-statement-revoke-privileges.md | 2 +- 6 files changed, 15 insertions(+), 11 deletions(-) diff --git a/TOC.md b/TOC.md index d53dacf332efc..487f7b0ba3f05 100644 --- a/TOC.md +++ b/TOC.md @@ -627,7 +627,7 @@ - Privileges - [Security Compatibility with MySQL](/security-compatibility-with-mysql.md) - [Privilege Management](/privilege-management.md) - - [Column Privilege Management](/column-privilege-management.md) + - [Column-Level Privilege Management](/column-privilege-management.md) - [User Account Management](/user-account-management.md) - [TiDB Password Management](/password-management.md) - [Role-Based Access Control](/role-based-access-control.md) diff --git a/column-privilege-management.md b/column-privilege-management.md index bc26379a607f6..b21b2395603c7 100644 --- a/column-privilege-management.md +++ b/column-privilege-management.md @@ -1,11 +1,11 @@ -`` +--- title: Column-Level Privilege Management -summary: TiDB supports a MySQL-compatible column-level privilege management mechanism, allowing you to grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns of a table using `GRANT` or `REVOKE`, thus achieving finer-grained access control. +summary: TiDB supports a MySQL-compatible column-level privilege management mechanism, enabling you to grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns of a table using `GRANT` or `REVOKE`, thus achieving finer-grained access control. --- # Column-Level Privilege Management -Starting from version v8.5.6, TiDB supports a MySQL-compatible column-level privilege management mechanism. With column-level privileges, you can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns of a table, achieving finer-grained data access control. +Starting from v8.5.6, TiDB supports a MySQL-compatible column-level privilege management mechanism. With column-level privileges, you can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns of a table, achieving finer-grained data access control. > **Note:** > @@ -92,8 +92,8 @@ SHOW GRANTS FOR 'newuser'@'%'; After granting or revoking column-level privileges, TiDB performs privilege checks on columns referenced in SQL statements. For example: * `SELECT` statements: `SELECT` column privileges affect columns referenced in the `SELECT` list as well as `WHERE`, `ORDER BY`, and other clauses. -* `UPDATE` statements: Columns being updated in the `SET` clause require `UPDATE` column privileges. Columns read in expressions or conditions usually also require `SELECT` column privileges. -* `INSERT` statements: Columns being written to require `INSERT` column privileges. `INSERT INTO t VALUES (...)` is equivalent to writing to all columns. +* `UPDATE` statements: columns being updated in the `SET` clause require `UPDATE` column privileges. Columns read in expressions or conditions usually also require `SELECT` column privileges. +* `INSERT` statements: columns being written to require `INSERT` column privileges. `INSERT INTO t VALUES (...)` is equivalent to writing to all columns. In the following example, user `newuser` can only query `col1` and update `col3`: @@ -113,6 +113,7 @@ UPDATE tbl SET col3 = col1 WHERE col1 > 0; ## Compatibility differences with MySQL TiDB's column-level privileges are generally compatible with MySQL. However, there are differences in the following scenarios: + | Scenario | TiDB | MySQL | | :--------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Revoking column-level privileges not granted to a user | `REVOKE` executes successfully. | `REVOKE` throws an error. | @@ -120,7 +121,10 @@ TiDB's column-level privileges are generally compatible with MySQL. However, the ### Column pruning and privilege checks in view scenarios -When performing `SELECT` privilege checks on views, MySQL first prunes columns in the view's internal query and then checks the column privileges of the internal tables, making the checks relatively lenient in some scenarios. TiDB does not perform column pruning before privilege checks, so additional column privileges might be required. +When performing `SELECT` privilege checks on views, MySQL and TiDB differ as follows: + +- MySQL first prunes columns in the view's internal query and then checks the column privileges of the internal tables, making the checks relatively lenient in some scenarios. +- TiDB does not perform column pruning before privilege checks, so additional column privileges might be required. ```sql -- Prepare the environment by logging in as root diff --git a/mysql-compatibility.md b/mysql-compatibility.md index 7ca47c028cd10..28c3310d56018 100644 --- a/mysql-compatibility.md +++ b/mysql-compatibility.md @@ -51,7 +51,7 @@ You can try out TiDB features on [TiDB Playground](https://play.tidbcloud.com/?u > Currently, only {{{ .starter }}} and {{{ .essential }}} clusters in certain AWS regions support [`FULLTEXT` syntax and indexes](https://docs.pingcap.com/tidbcloud/vector-search-full-text-search-sql). TiDB Self-Managed and TiDB Cloud Dedicated support parsing the `FULLTEXT` syntax but do not support using the `FULLTEXT` indexes. + `SPATIAL` (also known as `GIS`/`GEOMETRY`) functions, data types and indexes [#6347](https://github.com/pingcap/tidb/issues/6347) -+ Character sets other than `ascii`, `latin1`, `binary`, `utf8`, `utf8mb4`, `gbk`, and `gb18030`. ++ Character sets other than `ascii`, `latin1`, `binary`, `utf8`, `utf8mb4`, and `gbk`. + Optimizer trace + XML Functions + X-Protocol [#1109](https://github.com/pingcap/tidb/issues/1109) diff --git a/privilege-management.md b/privilege-management.md index c7c8a8fe0256a..84dd974687f1d 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -29,7 +29,7 @@ Use the following statement to grant the `xxx` user all privileges on all databa ```sql GRANT ALL PRIVILEGES ON *.* TO 'xxx'@'%'; ``` -From v8.5.6, TiDB supports the MySQL-compatible column-level privilege management mechanism. You can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges for specific columns at the table level. For more information, see [Column Privilege Management](/column-privilege-management.md). +Starting from v8.5.6, TiDB supports the MySQL-compatible column-level privilege management mechanism. You can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges for specific columns at the table level. For more information, see [Column-Level Privilege Management](/column-privilege-management.md). By default, [`GRANT`](/sql-statements/sql-statement-grant-privileges.md) statements will return an error if the user specified does not exist. This behavior depends on if the [SQL mode](/system-variables.md#sql_mode) `NO_AUTO_CREATE_USER` is specified: diff --git a/sql-statements/sql-statement-grant-privileges.md b/sql-statements/sql-statement-grant-privileges.md index 34415b25b8ffa..3253e69f2728f 100644 --- a/sql-statements/sql-statement-grant-privileges.md +++ b/sql-statements/sql-statement-grant-privileges.md @@ -82,7 +82,7 @@ mysql> SHOW GRANTS FOR 'newuser'; ## MySQL compatibility * Similar to MySQL, the `USAGE` privilege denotes the ability to log into a TiDB server. -* Starting from v8.5.6, TiDB supports a MySQL-compatible column-level privilege management mechanism. You can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns at the table level. For more information, see [Column-level privilege management](/column-privilege-management.md). +* Starting from v8.5.6, TiDB supports a MySQL-compatible column-level privilege management mechanism. You can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges on specific columns at the table level. For more information, see [Column-Level Privilege Management](/column-privilege-management.md). * Similar to MySQL, when the `NO_AUTO_CREATE_USER` sql mode is not present, the `GRANT` statement will automatically create a new user with an empty password when a user does not exist. Removing this sql-mode (it is enabled by default) presents a security risk. * In TiDB, after the `GRANT ` statement is executed successfully, the execution result takes effect immediately on the current connection. Whereas [in MySQL, for some privileges, the execution results take effect only on subsequent connections](https://dev.mysql.com/doc/refman/8.0/en/privilege-changes.html). See [TiDB #39356](https://github.com/pingcap/tidb/issues/39356) for details. diff --git a/sql-statements/sql-statement-revoke-privileges.md b/sql-statements/sql-statement-revoke-privileges.md index ccd419e006d70..30136fb944e25 100644 --- a/sql-statements/sql-statement-revoke-privileges.md +++ b/sql-statements/sql-statement-revoke-privileges.md @@ -6,7 +6,7 @@ summary: An overview of the usage of REVOKE for the TiDB database. # `REVOKE ` This statement removes privileges from an existing user. Executing this statement requires the `GRANT OPTION` privilege and all privileges you revoke. -Starting from TiDB v8.5.6 and subsequent 8.5.x versions, TiDB supports the MySQL-compatible column-level privilege management mechanism. You can specify a list of column names in `REVOKE`, for example `REVOKE SELECT(col2) ON test.tbl FROM 'user'@'host';`. For more information, see [Column Privilege Management](/column-privilege-management.md). +Starting from v8.5.6, TiDB supports the MySQL-compatible column-level privilege management mechanism. You can specify a list of column names in `REVOKE`, for example `REVOKE SELECT(col2) ON test.tbl FROM 'user'@'host';`. For more information, see [Column-Level Privilege Management](/column-privilege-management.md). ## Synopsis From 96062690badf1ea9b40c3199cee2d1b3a0493575 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Wed, 18 Mar 2026 15:25:23 +0800 Subject: [PATCH 6/9] Update sql-statements/sql-statement-revoke-privileges.md --- sql-statements/sql-statement-revoke-privileges.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sql-statements/sql-statement-revoke-privileges.md b/sql-statements/sql-statement-revoke-privileges.md index 30136fb944e25..0ab9b47106687 100644 --- a/sql-statements/sql-statement-revoke-privileges.md +++ b/sql-statements/sql-statement-revoke-privileges.md @@ -6,6 +6,7 @@ summary: An overview of the usage of REVOKE for the TiDB database. # `REVOKE ` This statement removes privileges from an existing user. Executing this statement requires the `GRANT OPTION` privilege and all privileges you revoke. + Starting from v8.5.6, TiDB supports the MySQL-compatible column-level privilege management mechanism. You can specify a list of column names in `REVOKE`, for example `REVOKE SELECT(col2) ON test.tbl FROM 'user'@'host';`. For more information, see [Column-Level Privilege Management](/column-privilege-management.md). ## Synopsis From 8736622630d7b45592c7a42795b5470c182fecf4 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Wed, 18 Mar 2026 15:25:43 +0800 Subject: [PATCH 7/9] Update privilege-management.md --- privilege-management.md | 1 + 1 file changed, 1 insertion(+) diff --git a/privilege-management.md b/privilege-management.md index 84dd974687f1d..3423d532dddbc 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -29,6 +29,7 @@ Use the following statement to grant the `xxx` user all privileges on all databa ```sql GRANT ALL PRIVILEGES ON *.* TO 'xxx'@'%'; ``` + Starting from v8.5.6, TiDB supports the MySQL-compatible column-level privilege management mechanism. You can grant or revoke `SELECT`, `INSERT`, `UPDATE`, and `REFERENCES` privileges for specific columns at the table level. For more information, see [Column-Level Privilege Management](/column-privilege-management.md). By default, [`GRANT`](/sql-statements/sql-statement-grant-privileges.md) statements will return an error if the user specified does not exist. This behavior depends on if the [SQL mode](/system-variables.md#sql_mode) `NO_AUTO_CREATE_USER` is specified: From f0cf0e1e4abbee5e6a159908544a375f817e28e7 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Wed, 18 Mar 2026 15:32:00 +0800 Subject: [PATCH 8/9] Update column-privilege-management.md --- column-privilege-management.md | 1 - 1 file changed, 1 deletion(-) diff --git a/column-privilege-management.md b/column-privilege-management.md index b21b2395603c7..370b17c9a3d2a 100644 --- a/column-privilege-management.md +++ b/column-privilege-management.md @@ -170,4 +170,3 @@ SELECT * FROM v; * [Privilege Management](/privilege-management.md) * [`GRANT `](/sql-statements/sql-statement-grant-privileges.md) * [`REVOKE `](/sql-statements/sql-statement-revoke-privileges.md) -``` From ce4c067106d6354903c40af2e85014b6ab361a74 Mon Sep 17 00:00:00 2001 From: houfaxin Date: Thu, 19 Mar 2026 09:49:55 +0800 Subject: [PATCH 9/9] Document INFORMATION_SCHEMA privilege support Update docs to reflect implemented privilege visibility in INFORMATION_SCHEMA and mysql system tables. - Mark COLUMN_PRIVILEGES, SCHEMA_PRIVILEGES, and TABLE_PRIVILEGES as summarizing privilege information visible to the current user (information-schema.md). - Remove an obsolete link and clarify viewing column-level privileges via INFORMATION_SCHEMA.COLUMN_PRIVILEGES (column-privilege-management.md). - Note that mysql.columns_priv is supported starting in v8.5.6 (privilege-management.md). These changes align the documentation with implemented behavior for column-, schema-, and table-level privilege reporting. --- column-privilege-management.md | 2 +- information-schema/information-schema.md | 6 +++--- privilege-management.md | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/column-privilege-management.md b/column-privilege-management.md index 370b17c9a3d2a..06dce59476ea3 100644 --- a/column-privilege-management.md +++ b/column-privilege-management.md @@ -67,7 +67,7 @@ SHOW GRANTS FOR 'newuser'@'%'; +---------------------------------------------------------------------+ ``` -In addition to using `SHOW GRANTS`, you can also view column-level privilege information by querying [`INFORMATION_SCHEMA.COLUMN_PRIVILEGES`](/information-schema/information-schema-columns.md). +In addition to using `SHOW GRANTS`, you can also view column-level privilege information by querying `INFORMATION_SCHEMA.COLUMN_PRIVILEGES`. ## Revoke column-level privileges diff --git a/information-schema/information-schema.md b/information-schema/information-schema.md index 9f949f0cef976..5222584760617 100644 --- a/information-schema/information-schema.md +++ b/information-schema/information-schema.md @@ -20,7 +20,7 @@ Many `INFORMATION_SCHEMA` tables have a corresponding `SHOW` statement. The bene | [`COLLATIONS`](/information-schema/information-schema-collations.md) | Provides a list of collations that the server supports. | | [`COLLATION_CHARACTER_SET_APPLICABILITY`](/information-schema/information-schema-collation-character-set-applicability.md) | Explains which collations apply to which character sets. | | [`COLUMNS`](/information-schema/information-schema-columns.md) | Provides a list of columns for all tables. | -| `COLUMN_PRIVILEGES` | Not implemented by TiDB. Returns zero rows. | +| `COLUMN_PRIVILEGES` | Summarizes the information about column privileges visible to the current user. | | `COLUMN_STATISTICS` | Not implemented by TiDB. Returns zero rows. | | [`ENGINES`](/information-schema/information-schema-engines.md) | Provides a list of supported storage engines. | | `EVENTS` | Not implemented by TiDB. Returns zero rows. | @@ -38,14 +38,14 @@ Many `INFORMATION_SCHEMA` tables have a corresponding `SHOW` statement. The bene | `REFERENTIAL_CONSTRAINTS` | Provides information on `FOREIGN KEY` constraints. | | `ROUTINES` | Not implemented by TiDB. Returns zero rows. | | [`SCHEMATA`](/information-schema/information-schema-schemata.md) | Provides similar information to `SHOW DATABASES`. | -| `SCHEMA_PRIVILEGES` | Not implemented by TiDB. Returns zero rows. | +| `SCHEMA_PRIVILEGES` | Summarizes the database privileges visible to the current user. | | `SESSION_STATUS` | Not implemented by TiDB. Returns zero rows. | | [`SESSION_VARIABLES`](/information-schema/information-schema-session-variables.md) | Provides similar functionality to the command `SHOW SESSION VARIABLES` | | [`STATISTICS`](/information-schema/information-schema-statistics.md) | Provides information on table indexes. | | [`TABLES`](/information-schema/information-schema-tables.md) | Provides a list of tables that the current user has visibility of. Similar to `SHOW TABLES`. | | `TABLESPACES` | Not implemented by TiDB. Returns zero rows. | | [`TABLE_CONSTRAINTS`](/information-schema/information-schema-table-constraints.md) | Provides information on primary keys, unique indexes and foreign keys. | -| `TABLE_PRIVILEGES` | Not implemented by TiDB. Returns zero rows. | +| `TABLE_PRIVILEGES` | Summarizes the table privileges visible to the current user. | | `TRIGGERS` | Not implemented by TiDB. Returns zero rows. | | [`USER_ATTRIBUTES`](/information-schema/information-schema-user-attributes.md) | Summarizes information about user comments and user attributes. | | [`USER_PRIVILEGES`](/information-schema/information-schema-user-privileges.md) | Summarizes the privileges associated with the current user. | diff --git a/privilege-management.md b/privilege-management.md index 3423d532dddbc..b3cd21d2b3fa5 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -508,7 +508,7 @@ The following [`mysql` system tables](/mysql-schema/mysql-schema.md) are special - `mysql.user` (user account, global privilege) - `mysql.db` (database-level privilege) - `mysql.tables_priv` (table-level privilege) -- `mysql.columns_priv` (column-level privilege; not currently supported) +- `mysql.columns_priv` (column-level privilege; supported starting from v8.5.6) These tables contain the effective range and privilege information of the data. For example, in the `mysql.user` table: