(718,'CREATE TABLESPACE',38,'The CREATE TABLESPACE statement is not supported by MariaDB. It was originally\ninherited from MySQL NDB Cluster. In MySQL 5.7 and later, the statement is\nalso supported for InnoDB. However, MariaDB has chosen not to include that\nspecific feature. See MDEV-19294 for more information.\n\nURL: https://mariadb.com/kb/en/create-tablespace/','','https://mariadb.com/kb/en/create-tablespace/'),
(720,'CREATE VIEW',38,'Syntax\n------\n\nCREATE\n  [OR REPLACE]\n  [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]\n  [DEFINER = { user | CURRENT_USER | role | CURRENT_ROLE }]\n  [SQL SECURITY { DEFINER | INVOKER }]\n  VIEW [IF NOT EXISTS] view_name [(column_list)]\n  AS select_statement\n  [WITH [CASCADED | LOCAL] CHECK OPTION]\n\nDescription\n-----------\n\nThe CREATE VIEW statement creates a new view, or replaces an existing one if\nthe OR REPLACE clause is given. If the view does not exist, CREATE OR REPLACE\nVIEW is the same as CREATE VIEW. If the view does exist, CREATE OR REPLACE\nVIEW is the same as ALTER VIEW.\n\nThe select_statement is a SELECT statement that provides the definition of the\nview. (When you select from the view, you select in effect using the SELECT\nstatement.) select_statement can select from base tables or other views.\n\nThe view definition is \"frozen\" at creation time, so changes to the underlying\ntables afterwards do not affect the view definition. For example, if a view is\ndefined as SELECT * on a table, new columns added to the table later do not\nbecome part of the view. A SHOW CREATE VIEW shows that such queries are\nrewritten and column names are included in the view definition.\n\nThe view definition must be a query that does not return errors at view\ncreation times. However, the base tables used by the views might be altered\nlater and the query may not be valid anymore. In this case, querying the view\nwill result in an error. CHECK TABLE helps in finding this kind of problems.\n\nThe ALGORITHM clause affects how MariaDB processes the view. The DEFINER and\nSQL SECURITY clauses specify the security context to be used when checking\naccess privileges at view invocation time. The WITH CHECK OPTION clause can be\ngiven to constrain inserts or updates to rows in tables referenced by the\nview. These clauses are described later in this section.\n\nThe CREATE VIEW statement requires the CREATE VIEW privilege for the view, and\nsome privilege for each column selected by the SELECT statement. For columns\nused elsewhere in the SELECT statement you must have the SELECT privilege. If\nthe OR REPLACE clause is present, you must also have the DROP privilege for\nthe view.\n\nA view belongs to a database. By default, a new view is created in the default\ndatabase. To create the view explicitly in a given database, specify the name\nas db_name.view_name when you create it.\n\nCREATE VIEW test.v AS SELECT * FROM t;\n\nBase tables and views share the same namespace within a database, so a\ndatabase cannot contain a base table and a view that have the same name.\n\nViews must have unique column names with no duplicates, just like base tables.\nBy default, the names of the columns retrieved by the SELECT statement are\nused for the view column names. To define explicit names for the view columns,\nthe optional column_list clause can be given as a list of comma-separated\nidentifiers. The number of names in column_list must be the same as the number\nof columns retrieved by the SELECT statement.\n\nMySQL until 5.1.28\n------------------\nPrior to MySQL 5.1.29, When you modify an existing view, the current view\ndefinition is backed up and saved. It is stored in that table\'s database\ndirectory, in a subdirectory named arc. The backup file for a view v is named\nv.frm-00001. If you alter the view again, the next backup is named\nv.frm-00002. The three latest view backup definitions are stored. Backed up\nview definitions are not preserved by mysqldump, or any other such programs,\nbut you can retain them using a file copy operation. However, they are not\nneeded for anything but to provide you with a backup of your previous view\ndefinition. It is safe to remove these backup definitions, but only while\nmysqld is not running. If you delete the arc subdirectory or its files while\nmysqld is running, you will receive an error the next time you try to alter\nthe view:\n\nMariaDB [test]> ALTER VIEW v AS SELECT * FROM t; \nERROR 6 (HY000): Error on delete of \'.\\test\\arc/v.frm-0004\' (Errcode: 2)\n\nColumns retrieved by the SELECT statement can be simple references to table\ncolumns. They can also be expressions that use functions, constant values,\noperators, and so forth.\n\nUnqualified table or view names in the SELECT statement are interpreted with\nrespect to the default database. A view can refer to tables or views in other\ndatabases by qualifying the table or view name with the proper database name.\n\nA view can be created from many kinds of SELECT statements. It can refer to\nbase tables or other views. It can use joins, UNION, and subqueries. The\nSELECT need not even refer to any tables. The following example defines a view\nthat selects two columns from another table, as well as an expression\ncalculated from those columns:\n\nCREATE TABLE t (qty INT, price INT);\n\nINSERT INTO t VALUES(3, 50);\n\nCREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t;\n\nSELECT * FROM v;\n+------+-------+-------+\n| qty  | price | value |\n+------+-------+-------+\n|    3 |    50 |   150 |\n+------+-------+-------+\n\nA view definition is subject to the following restrictions:\n\n* The SELECT statement cannot contain a subquery in the FROM clause.\n* The SELECT statement cannot refer to system or user variables.\n* Within a stored program, the definition cannot refer to program parameters\nor local variables.\n* The SELECT statement cannot refer to prepared statement parameters.\n* Any table or view referred to in the definition must exist. However, after a\nview has been created, it is possible to drop a table or view that the\ndefinition refers to. In this case, use of the view results in an error. To\ncheck a view definition for problems of this kind, use the CHECK TABLE\nstatement.\n* The definition cannot refer to a TEMPORARY table, and you cannot create a\nTEMPORARY view.\n* Any tables named in the view definition must exist at definition time.\n* You cannot associate a trigger with a view.\n* For valid identifiers to use as view names, see Identifier Names.\n\nORDER BY is allowed in a view definition, but it is ignored if you select from\na view using a statement that has its own ORDER BY.\n\nFor other options or clauses in the definition, they are added to the options\nor clauses of the statement that references the view, but the effect is\nundefined. For example, if a view definition includes a LIMIT clause, and you\nselect from the view using a statement that has its own LIMIT clause, it is\nundefined which limit applies. This same principle applies to options such as\nALL, DISTINCT, or SQL_SMALL_RESULT that follow the SELECT keyword, and to\nclauses such as INTO, FOR UPDATE, and LOCK IN SHARE MODE.\n\nThe PROCEDURE clause cannot be used in a view definition, and it cannot be\nused if a view is referenced in the FROM clause.\n\nIf you create a view and then change the query processing environment by\nchanging system variables, that may affect the results that you get from the\nview:\n\nCREATE VIEW v (mycol) AS SELECT \'abc\';\n\nSET sql_mode = \'\';\n\nSELECT \"mycol\" FROM v;\n+-------+\n| mycol |\n+-------+\n| mycol | \n+-------+\n\nSET sql_mode = \'ANSI_QUOTES\';\n\nSELECT \"mycol\" FROM v;\n+-------+\n| mycol |\n+-------+\n| abc   | \n+-------+\n\nThe DEFINER and SQL SECURITY clauses determine which MariaDB account to use\nwhen checking access privileges for the view when a statement is executed that\nreferences the view. They were added in MySQL 5.1.2. The legal SQL SECURITY\ncharacteristic values are DEFINER and INVOKER. These indicate that the\nrequired privileges must be held by the user who defined or invoked the view,\nrespectively. The default SQL SECURITY value is DEFINER.\n\nIf a user value is given for the DEFINER clause, it should be a MariaDB\naccount in \'user_name\'@\'host_name\' format (the same format used in the GRANT\nstatement). The user_name and host_name values both are required. The definer\ncan also be given as CURRENT_USER or CURRENT_USER(). The default DEFINER value\nis the user who executes the CREATE VIEW statement. This is the same as\nspecifying DEFINER = CURRENT_USER explicitly.\n\nIf you specify the DEFINER clause, these rules determine the legal DEFINER\nuser values:\n\n* If you do not have the SUPER privilege, or, from MariaDB 10.5.2, the SET\nUSER privilege, the only legal user value is your own account, either\nspecified literally or by using CURRENT_USER. You cannot set the definer to\nsome other account.\n* If you have the SUPER privilege, or, from MariaDB 10.5.2, the SET USER\nprivilege, you can specify any syntactically legal account name. If the\naccount does not actually exist, a warning is generated.\n* If the SQL SECURITY value is DEFINER but the definer account does not exist\nwhen the view is referenced, an error occurs.\n\nWithin a view definition, CURRENT_USER returns the view\'s DEFINER value by\ndefault. For views defined with the SQL SECURITY INVOKER characteristic,\nCURRENT_USER returns the account for the view\'s invoker. For information about\nuser auditing within views, see\nhttp://dev.mysql.com/doc/refman/5.1/en/account-activity-auditing.html.\n\nWithin a stored routine that is defined with the SQL SECURITY DEFINER\ncharacteristic, CURRENT_USER returns the routine\'s DEFINER value. This also\naffects a view defined within such a program, if the view definition contains\na DEFINER value of CURRENT_USER.\n\nView privileges are checked like this:\n\n* At view definition time, the view creator must have the privileges needed to\nuse the top-level objects accessed by the view. For example, if the view\ndefinition refers to table columns, the creator must have privileges for the\ncolumns, as described previously. If the definition refers to a stored\nfunction, only the privileges needed to invoke the function can be checked.\nThe privileges required when the function runs can be checked only as it\nexecutes: For different invocations of the function, different execution paths\nwithin the function might be taken.\n* When a view is referenced, privileges for objects accessed by the view are\nchecked against the privileges held by the view creator or invoker, depending\non whether the SQL SECURITY characteristic is DEFINER or INVOKER, respectively.\n* If reference to a view causes execution of a stored function, privilege\nchecking for statements executed within the function depend on whether the\nfunction is defined with a SQL SECURITY characteristic of DEFINER or INVOKER.\nIf the security characteristic is DEFINER, the function runs with the\nprivileges of its creator. If the characteristic is INVOKER, the function runs\nwith the privileges determined by the view\'s SQL SECURITY characteristic.\n\nExample: A view might depend on a stored function, and that function might\ninvoke other stored routines. For example, the following view invokes a stored\nfunction f():\n\nCREATE VIEW v AS SELECT * FROM t WHERE t.id = f(t.name);\n\nSuppose that f() contains a statement such as this:\n\nIF name IS NULL then\n CALL p1();\nELSE\n CALL p2();\nEND IF;\n\nThe privileges required for executing statements within f() need to be checked\nwhen f() executes. This might mean that privileges are needed for p1() or\np2(), depending on the execution path within f(). Those privileges must be\nchecked at runtime, and the user who must possess the privileges is determined\nby the SQL SECURITY values of the view v and the function f().\n\nThe DEFINER and SQL SECURITY clauses for views are extensions to standard SQL.\nIn standard SQL, views are handled using the rules for SQL SECURITY INVOKER.\n\nIf you invoke a view that was created before MySQL 5.1.2, it is treated as\nthough it was created with a SQL SECURITY DEFINER clause and with a DEFINER\nvalue that is the same as your account. However, because the actual definer is\nunknown, MySQL issues a warning. To make the warning go away, it is sufficient\nto re-create the view so that the view definition includes a DEFINER clause.\n\nThe optional ALGORITHM clause is an extension to standard SQL. It affects how\nMariaDB processes the view. ALGORITHM takes three values: MERGE, TEMPTABLE, or\nUNDEFINED. The default algorithm is UNDEFINED if no ALGORITHM clause is\npresent. See View Algorithms for more information.\n\nSome views are updatable. That is, you can use them in statements such as\nUPDATE, DELETE, or INSERT to update the contents of the underlying table. For\na view to be updatable, there must be a one-to-one relationship between the\nrows in the view and the rows in the underlying table. There are also certain\nother constructs that make a view non-updatable. See Inserting and Updating\nwith Views.\n\nWITH CHECK OPTION\n-----------------\n\nThe WITH CHECK OPTION clause can be given for an updatable view to prevent\ninserts or updates to rows except those for which the WHERE clause in the\nselect_statement is true.\n\nIn a WITH CHECK OPTION clause for an updatable view, the LOCAL and CASCADED\nkeywords determine the scope of check testing when the view is defined in\nterms of another view. The LOCAL keyword restricts the CHECK OPTION only to\nthe view being defined. CASCADED causes the checks for underlying views to be\nevaluated as well. When neither keyword is given, the default is CASCADED.\n\nFor more information about updatable views and the WITH CHECK OPTION clause,\nsee Inserting and Updating with Views.\n\nIF NOT EXISTS\n-------------\n\nMariaDB starting with 10.1.3\n----------------------------\nThe IF NOT EXISTS clause was added in MariaDB 10.1.3\n\nWhen the IF NOT EXISTS clause is used, MariaDB will return a warning instead\nof an error if the specified view already exists. Cannot be used together with\nthe OR REPLACE clause.\n\nAtomic DDL\n----------\n\nMariaDB starting with 10.6.1\n----------------------------\nMariaDB 10.6.1 supports Atomic DDL and CREATE VIEW is atomic.\n\nExamples\n--------\n\nCREATE TABLE t (a INT, b INT) ENGINE = InnoDB;\n\nINSERT INTO t VALUES (1,1), (2,2), (3,3);\n\nCREATE VIEW v AS SELECT a, a*2 AS a2 FROM t;\n\nSELECT * FROM v;\n+------+------+\n| a    | a2   |\n+------+------+\n|    1 |    2 |\n|    2 |    4 |\n|    3 |    6 |\n+------+------+\n\nOR REPLACE and IF NOT EXISTS:\n\nCREATE VIEW v AS SELECT a, a*2 AS a2 FROM t;\nERROR 1050 (42S01): Table \'v\' already exists\n\nCREATE OR REPLACE VIEW v AS SELECT a, a*2 AS a2 FROM t;\nQuery OK, 0 rows affected (0.04 sec)\n\nCREATE VIEW IF NOT EXISTS v AS SELECT a, a*2 AS a2 FROM t;\nQuery OK, 0 rows affected, 1 warning (0.01 sec)\n\nSHOW WARNINGS;\n+-------+------+--------------------------+\n| Level | Code | Message                  |\n+-------+------+--------------------------+\n| Note  | 1050 | Table \'v\' already exists |\n+-------+------+--------------------------+\n\nURL: https://mariadb.com/kb/en/create-view/','','https://mariadb.com/kb/en/create-view/'),
(721,'Generated (Virtual and Persistent/Stored) Columns',38,'Syntax\n------\n\n<type>  [GENERATED ALWAYS]  AS   ( <expression> )\n[VIRTUAL | PERSISTENT | STORED]  [UNIQUE] [UNIQUE KEY] [COMMENT <text>]\n\nMariaDB\'s generated columns syntax is designed to be similar to the syntax for\nMicrosoft SQL Server\'s computed columns and Oracle Database\'s virtual columns.\nIn MariaDB 10.2 and later, the syntax is also compatible with the syntax for\nMySQL\'s generated columns.\n\nDescription\n-----------\n\nA generated column is a column in a table that cannot explicitly be set to a\nspecific value in a DML query. Instead, its value is automatically generated\nbased on an expression. This expression might generate the value based on the\nvalues of other columns in the table, or it might generate the value by\ncalling built-in functions or user-defined functions (UDFs).\n\nThere are two types of generated columns:\n\n* PERSISTENT (a.k.a. STORED): This type\'s value is actually stored in the\ntable.\n* VIRTUAL: This type\'s value is not stored at all. Instead, the value is\ngenerated dynamically when the table is queried. This type is the default.\n\nGenerated columns are also sometimes called computed columns or virtual\ncolumns.\n\nSupported Features\n------------------\n\nStorage Engine Support\n----------------------\n\n* Generated columns can only be used with storage engines which support them.\nIf you try to use a storage engine that does not support them, then you will\nsee an error similar to the following:\n\nERROR 1910 (HY000): TokuDB storage engine does not support computed columns\n\n* InnoDB, Aria, MyISAM and CONNECT support generated columns.\n\n* A column in a MERGE table can be built on a PERSISTENT generated column.\nHowever, a column in a MERGE table can not be defined as a VIRTUAL and\nPERSISTENT generated column.\n\nData Type Support\n-----------------\n\n* All data types are supported when defining generated columns.\n\n* Using the ZEROFILL column option is supported when defining generated\ncolumns.\n\n* Using the AUTO_INCREMENT column option is not supported when defining\ngenerated columns. Until MariaDB 10.2.25, it was supported, but this support\nwas removed, because it would not work correctly. See MDEV-11117.\n\nIndex Support\n-------------\n\n* Using a generated column as a table\'s primary key is not supported. See\nMDEV-5590 for more information. If you try to use one as a primary key, then\nyou will see an error similar to the following:\n\nERROR 1903 (HY000): Primary key cannot be defined upon a computed column\n\n* Using PERSISTENT generated columns as part of a foreign key is supported.\n\n* Referencing PERSISTENT generated columns as part of a foreign key is also\nsupported.\nHowever, using the ON UPDATE CASCADE, ON UPDATE SET NULL, or ON DELETE SET\nNULL clauses is not supported. If you try to use an unsupported clause, then\nyou will see an error similar to the following:\n\nERROR 1905 (HY000): Cannot define foreign key with ON UPDATE SET NULL clause\non a computed column\n\n* Defining indexes on both VIRTUAL and PERSISTENT generated columns is\nsupported.\nIf an index is defined on a generated column, then the optimizer considers\nusing it in the same way as indexes based on \"real\" columns.\n\nStatement Support\n-----------------\n\n* Generated columns are used in DML queries just as if they were \"real\"\ncolumns.\nHowever, VIRTUAL and PERSISTENT generated columns differ in how their data is\nstored.\nValues for PERSISTENT generated columns are generated whenever a DML queries\ninserts or updates the row with the special DEFAULT value. This generates the\ncolumns value, and it is stored in the table like the other \"real\" columns.\nThis value can be read by other DML queries just like the other \"real\" columns.\nValues for VIRTUAL generated columns are not stored in the table. Instead, the\nvalue is generated dynamically whenever the column is queried. If other\ncolumns in a row are queried, but the VIRTUAL generated column is not one of\nthe queried columns, then the column\'s value is not generated.\n\n* The SELECT statement supports generated columns.\n\n* Generated columns can be referenced in the INSERT, UPDATE, and DELETE\nstatements.\nHowever, VIRTUAL or PERSISTENT generated columns cannot be explicitly set to\nany other values than NULL or DEFAULT. If a generated column is explicitly set\nto any other value, then the outcome depends on whether strict mode is enabled\nin sql_mode. If it is not enabled, then a warning will be raised and the\ndefault generated value will be used instead. If it is enabled, then an error\nwill be raised instead.\n\n* The CREATE TABLE statement has limited support for generated columns.\nIt supports defining generated columns in a new table.\nIt supports using generated columns to partition tables.\nIt does not support using the versioning clauses with generated columns.\n\n* The ALTER TABLE statement has limited support for generated columns.\nIt supports the MODIFY and CHANGE clauses for PERSISTENT generated columns.\nIt does not support the MODIFY clause for VIRTUAL generated columns if\nALGORITHM is not set to COPY. See MDEV-15476 for more information.\nIt does not support the  CHANGE clause for VIRTUAL generated columns if\nALGORITHM is not set to COPY. See MDEV-17035 for more information.\nIt does not support altering a table if ALGORITHM is not set to COPY if the\ntable has a VIRTUAL generated column that is indexed. See MDEV-14046 for more\ninformation.\nIt does not support adding a VIRTUAL generated column with the ADD clause if\nthe same statement is also adding other columns if ALGORITHM is not set to\nCOPY. See MDEV-17468 for more information.\nIt also does not support altering an existing column into a VIRTUAL generated\ncolumn.\nIt supports using generated columns to partition tables.\nIt does not support using the versioning clauses with generated columns.\n\n* The SHOW CREATE TABLE statement supports generated columns.\n\n* The DESCRIBE statement can be used to check whether a table has generated\ncolumns.\nYou can tell which columns are generated by looking for the ones where the\nExtra column is set to either VIRTUAL or PERSISTENT. For example:\n\nDESCRIBE table1;\n+-------+-------------+------+-----+---------+------------+\n| Field | Type        | Null | Key | Default | Extra      |\n+-------+-------------+------+-----+---------+------------+\n| a     | int(11)     | NO   |     | NULL    |            |\n| b     | varchar(32) | YES  |     | NULL    |            |\n| c     | int(11)     | YES  |     | NULL    | VIRTUAL    |\n| d     | varchar(5)  | YES  |     | NULL    | PERSISTENT |\n+-------+-------------+------+-----+---------+------------+\n\n* Generated columns can be properly referenced in the NEW and OLD rows in\ntriggers.\n\n* Stored procedures support generated columns.\n\n* The HANDLER statement supports generated columns.\n\nExpression Support\n------------------\n\n* Most legal, deterministic expressions which can be calculated are supported\nin expressions for generated columns.\n\n* Most built-in functions are supported in expressions for generated columns.\nHowever, some built-in functions can\'t be supported for technical reasons. For\nexample,  If you try to use an unsupported function in an expression, an error\nis generated similar to the following:\n\nERROR 1901 (HY000): Function or expression \'dayname()\' cannot be used in the\nGENERATED ALWAYS AS clause of `v`\n\n* Subqueries are not supported in expressions for generated columns because\nthe underlying data can change.\n\n* Using anything that depends on data outside the row is not supported in\nexpressions for generated columns.\n\n* Stored functions are not supported in expressions for generated columns. See\nMDEV-17587 for more information.\n\n* Non-deterministic built-in functions are supported in expressions for not\nindexed VIRTUAL generated columns.\n\n* Non-deterministic built-in functions are not supported in expressions for\nPERSISTENT or indexed VIRTUAL generated columns.\n\n* User-defined functions (UDFs) are supported in expressions for generated\ncolumns.\nHowever, MariaDB can\'t check whether a UDF is deterministic, so it is up to\nthe user to be sure that they do not use non-deterministic UDFs with VIRTUAL\ngenerated columns.\n\n* Defining a generated column based on other generated columns defined before\nit in the table definition is supported. For example:\n\nCREATE TABLE t1 (a int as (1), b int as (a));\n\n* However, defining a generated column based on other generated columns\ndefined after in the table definition is not supported in expressions for\ngeneration columns because generated columns are calculated in the order they\nare defined.\n\n* Using an expression that exceeds 255 characters in length is supported in\nexpressions for generated columns. The new limit for the entire table\ndefinition, including all expressions for generated columns, is 65,535 bytes.\n\n* Using constant expressions is supported in expressions for generated\ncolumns. For example:\n\nCREATE TABLE t1 (a int as (1));\n\nMaking Stored Values Consistent\n-------------------------------\n\nWhen a generated column is PERSISTENT or indexed, the value of the expression\nneeds to be consistent regardless of the SQL Mode flags in the current\nsession. If it is not, then the table will be seen as corrupted when the value\nthat should actually be returned by the computed expression and the value that\nwas previously stored and/or indexed using a different sql_mode setting\ndisagree.\n\nThere are currently two affected classes of inconsistencies: character padding\nand unsigned subtraction:\n\n* For a VARCHAR or TEXT generated column the length of the value returned can\nvary depending on the PAD_CHAR_TO_FULL_LENGTH sql_mode flag.  To make the\nvalue consistent, create the generated column using an RTRIM() or RPAD()\nfunction.  Alternately, create the generated column as a CHAR column so that\nits data is always fully padded.\n\n* If a SIGNED generated column is based on the subtraction of an UNSIGNED\nvalue, the resulting value can vary depending on how large the value is and\nthe NO_UNSIGNED_SUBTRACTION sql_mode flag.  To make the value consistent, use\nCAST() to ensure that each UNSIGNED operand is SIGNED before the subtraction.\n\nMariaDB starting with 10.5\n--------------------------\nBeginning in MariaDB 10.5, there is a fatal error generated when trying to\ncreate a generated column whose value can change depending on the SQL Mode\nwhen its data is PERSISTENT or indexed.\n\nFor an existing generated column that has a potentially inconsistent value, a\nwarning about a bad expression is generated the first time it is used (if\nwarnings are enabled).\n\nBeginning in MariaDB 10.4.8, MariaDB 10.3.18, and MariaDB 10.2.27 a\npotentially inconsistent generated column outputs a warning when created or\nfirst used (without restricting their creation).\n\nHere is an example of two tables that would be rejected in MariaDB 10.5 and\nwarned about in the other listed versions:\n\nCREATE TABLE bad_pad (\n txt CHAR(5),\n -- CHAR -> VARCHAR or CHAR -> TEXT can\'t be persistent or indexed:\n vtxt VARCHAR(5) AS (txt) PERSISTENT\n);\n\nCREATE TABLE bad_sub (\n num1 BIGINT UNSIGNED,\n num2 BIGINT UNSIGNED,\n -- The resulting value can vary for some large values\n vnum BIGINT AS (num1 - num2) VIRTUAL,\n KEY(vnum)\n);\n\nThe warnings for the above tables look like this:\n\nWarning (Code 1901): Function or expression \'`txt`\' cannot be used in the\nGENERATED ALWAYS AS clause of `vtxt`\nWarning (Code 1105): Expression depends on the @@sql_mode value\nPAD_CHAR_TO_FULL_LENGTH\n\nWarning (Code 1901): Function or expression \'`num1` - `num2`\' cannot be used\nin the GENERATED ALWAYS AS clause of `vnum`\nWarning (Code 1105): Expression depends on the @@sql_mode value\nNO_UNSIGNED_SUBTRACTION\n\nTo work around the issue, force the padding or type to make the generated\ncolumn\'s expression return a consistent value. For example:\n\nCREATE TABLE good_pad (\n txt CHAR(5),\n -- Using RTRIM() or RPAD() makes the value consistent:\n vtxt VARCHAR(5) AS (RTRIM(txt)) PERSISTENT,\n -- When not persistent or indexed, it is OK for the value to vary by mode:\n vtxt2 VARCHAR(5) AS (txt) VIRTUAL,\n -- CHAR -> CHAR is always OK:\n txt2 CHAR(5) AS (txt) PERSISTENT\n);\n\nCREATE TABLE good_sub (\n num1 BIGINT UNSIGNED,\n num2 BIGINT UNSIGNED,\n -- The indexed value will always be consistent in this expression:\n vnum BIGINT AS (CAST(num1 AS SIGNED) - CAST(num2 AS SIGNED)) VIRTUAL,\n KEY(vnum)\n);\n\nMySQL Compatibility Support\n---------------------------\n\n* The STORED keyword is supported as an alias for the PERSISTENT keyword.\n\n* Tables created with MySQL 5.7 or later that contain MySQL\'s generated\ncolumns can be imported into MariaDB without a dump and restore.\n\nImplementation Differences\n--------------------------\n\nGenerated columns are subject to various constraints in other DBMSs that are\nnot present in MariaDB\'s implementation. Generated columns may also be called\ncomputed columns or virtual columns in different implementations. The various\ndetails for a specific implementation can be found in the documentation for\neach specific DBMS.\n\nImplementation Differences Compared to Microsoft SQL Server\n-----------------------------------------------------------\n\nMariaDB\'s generated columns implementation does not enforce the following\nrestrictions that are present in Microsoft SQL Server\'s computed columns\nimplementation:\n\n* MariaDB allows server variables in generated column expressions, including\nthose that change dynamically, such as warning_count.\n* MariaDB allows the CONVERT_TZ() function to be called with a named time zone\nas an argument, even though time zone names and time offsets are configurable.\n* MariaDB allows the CAST() function to be used with non-unicode character\nsets, even though character sets are configurable and differ between\nbinaries/versions.\n* MariaDB allows FLOAT expressions to be used in generated columns. Microsoft\nSQL Server considers these expressions to be \"imprecise\" due to potential\ncross-platform differences in floating-point implementations and precision.\n* Microsoft SQL Server requires the ARITHABORT mode to be set, so that\ndivision by zero returns an error, and not a NULL.\n* Microsoft SQL Server requires QUOTED_IDENTIFIER to be set in sql_mode. In\nMariaDB, if data is inserted without ANSI_QUOTES set in sql_mode, then it will\nbe processed and stored differently in a generated column that contains quoted\nidentifiers.\n\nMicrosoft SQL Server enforces the above restrictions by doing one of the\nfollowing things:\n\n* Refusing to create computed columns.\n* Refusing to allow updates to a table containing them.\n* Refusing to use an index over such a column if it can not be guaranteed that\nthe expression is fully deterministic.\n\nIn MariaDB, as long as the sql_mode, language, and other settings that were in\neffect during the CREATE TABLE remain unchanged, the generated column\nexpression will always be evaluated the same. If any of these things change,\nthen please be aware that the generated column expression might not be\nevaluated the same way as it previously was.\n\nIf you try to update a virtual column, you will get an error if the default\nstrict mode is enabled in sql_mode, or a warning otherwise.\n\nDevelopment History\n-------------------\n\nGenerated columns was originally developed by Andrey Zhakov. It was then\nmodified by Sanja Byelkin and Igor Babaev at Monty Program for inclusion in\nMariaDB. Monty did the work on MariaDB 10.2 to lift a some of the old\nlimitations.\n\nExamples\n--------\n\nHere is an example table that uses both VIRTUAL and PERSISTENT virtual columns:\n\nUSE TEST;\n\nCREATE TABLE table1 (\n  a INT NOT NULL,\n  b VARCHAR(32),\n  c INT AS (a mod 10) VIRTUAL,\n  d VARCHAR(5) AS (left(b,5)) PERSISTENT);\n\nIf you describe the table, you can easily see which columns are virtual by\nlooking in the \"Extra\" column:\n\nDESCRIBE table1;\n+-------+-------------+------+-----+---------+------------+\n| Field | Type        | Null | Key | Default | Extra      |\n+-------+-------------+------+-----+---------+------------+\n| a     | int(11)     | NO   |     | NULL    |            |\n| b     | varchar(32) | YES  |     | NULL    |            |\n| c     | int(11)     | YES  |     | NULL    | VIRTUAL    |\n| d     | varchar(5)  | YES  |     | NULL    | PERSISTENT |\n+-------+-------------+------+-----+---------+------------+\n\nTo find out what function(s) generate the value of the virtual column you can\nuse SHOW CREATE TABLE:\n\nSHOW CREATE TABLE table1;\n\n| table1 | CREATE TABLE `table1` (\n `a` int(11) NOT NULL,\n `b` varchar(32) DEFAULT NULL,\n `c` int(11) AS (a mod 10) VIRTUAL,\n `d` varchar(5) AS (left(b,5)) PERSISTENT\n) ENGINE=MyISAM DEFAULT CHARSET=latin1 |\n\nIf you try to insert non-default values into a virtual column, you will\nreceive a warning and what you tried to insert will be ignored and the derived\nvalue inserted instead:\n\nWARNINGS;\nShow warnings enabled.\n\nINSERT INTO table1 VALUES (1, \'some text\',default,default);\nQuery OK, 1 row affected (0.00 sec)\n\nINSERT INTO table1 VALUES (2, \'more text\',5,default);\nQuery OK, 1 row affected, 1 warning (0.00 sec)\n\nWarning (Code 1645): The value specified for computed column \'c\' in table\n\'table1\' has been ignored.\n\nINSERT INTO table1 VALUES (123, \'even more text\',default,\'something\');\nQuery OK, 1 row affected, 2 warnings (0.00 sec)\n\nWarning (Code 1645): The value specified for computed column \'d\' in table\n\'table1\' has been ignored.\nWarning (Code 1265): Data truncated for column \'d\' at row 1\n\nSELECT * FROM table1;\n+-----+----------------+------+-------+\n| a   | b              | c    | d     |\n+-----+----------------+------+-------+\n|   1 | some text      |    1 | some  |\n|   2 | more text      |    2 | more  |\n| 123 | even more text |    3 | even  |\n+-----+----------------+------+-------+\n3 rows in set (0.00 sec)\n\nIf the ZEROFILL clause is specified, it should be placed directly after the\ntype definition, before the AS (<expression>):\n\nCREATE TABLE table2 (a INT, b INT ZEROFILL AS (a*2) VIRTUAL);\nINSERT INTO table2 (a) VALUES (1);\n\nSELECT * FROM table2;\n+------+------------+\n| a    | b          |\n+------+------------+\n|    1 | 0000000002 |\n+------+------------+\n1 row in set (0.00 sec)\n\nYou can also use virtual columns to implement a \"poor man\'s partial index\".\nSee example at the end of Unique Index.\n\nURL: https://mariadb.com/kb/en/generated-columns/','','https://mariadb.com/kb/en/generated-columns/'),
(727,'DROP PACKAGE',38,'MariaDB starting with 10.3.5\n----------------------------\nOracle-style packages were introduced in MariaDB 10.3.5.\n\nSyntax\n------\n\nDROP PACKAGE [IF EXISTS]  [ db_name . ] package_name\n\nDescription\n-----------\n\nThe DROP PACKAGE statement can be used when Oracle SQL_MODE is set.\n\nThe DROP PACKAGE statement drops a stored package entirely:\n\n* Drops the package specification (earlier created using the CREATE PACKAGE\nstatement).\n* Drops the package implementation, if the implementation was already created\nusing the CREATE PACKAGE BODY statement.\n\nURL: https://mariadb.com/kb/en/drop-package/','','https://mariadb.com/kb/en/drop-package/'),
(288,'VARCHAR',23,'Syntax\n------\n\n[NATIONAL] VARCHAR(M) [CHARACTER SET charset_name] [COLLATE collation_name]\n\nDescription\n-----------\n\nA variable-length string. M represents the maximum column length in\ncharacters. The range of M is 0 to 65,532. The effective maximum length of a\nVARCHAR is subject to the maximum row size and the character set used. For\nexample, utf8 characters can require up to three bytes per character, so a\nVARCHAR column that uses the utf8 character set can be declared to be a\nmaximum of 21,844 characters.\n\nNote: For the ColumnStore engine, M represents the maximum column length in\nbytes.\n\nMariaDB stores VARCHAR values as a one-byte or two-byte length prefix plus\ndata. The length prefix indicates the number of bytes in the value. A VARCHAR\ncolumn uses one length byte if values require no more than 255 bytes, two\nlength bytes if values may require more than 255 bytes.\n\nMariaDB follows the standard SQL specification, and does not remove trailing\nspaces from VARCHAR values.\n\nVARCHAR(0) columns can contain 2 values: an empty string or NULL. Such columns\ncannot be part of an index. The CONNECT storage engine does not support\nVARCHAR(0).\n\nVARCHAR is shorthand for CHARACTER VARYING. NATIONAL VARCHAR is the standard\nSQL way to define that a VARCHAR column should use some predefined character\nset. MariaDB uses utf8 as this predefined character set, as does MySQL 4.1 and\nup. NVARCHAR is shorthand for NATIONAL VARCHAR.\n\nBefore MariaDB 10.2, all MariaDB collations were of type PADSPACE, meaning\nthat VARCHAR (as well as CHAR and TEXT values) are compared without regard for\ntrailing spaces. This does not apply to the LIKE pattern-matching operator,\nwhich takes into account trailing spaces. From MariaDB 10.2, a number of NO\nPAD collations are available.\n\nIf a unique index consists of a column where trailing pad characters are\nstripped or ignored, inserts into that column where values differ only by the\nnumber of trailing pad characters will result in a duplicate-key error.\n\nExamples\n--------\n\nThe following are equivalent:\n\nVARCHAR(30) CHARACTER SET utf8\nNATIONAL VARCHAR(30)\nNVARCHAR(30)\nNCHAR VARCHAR(30)\nNATIONAL CHARACTER VARYING(30)\nNATIONAL CHAR VARYING(30)\n\nTrailing spaces:\n\nCREATE TABLE strtest (v VARCHAR(10));\nINSERT INTO strtest VALUES(\'Maria   \');\n\nSELECT v=\'Maria\',v=\'Maria   \' FROM strtest;\n+-----------+--------------+\n| v=\'Maria\' | v=\'Maria   \' |\n+-----------+--------------+\n|         1 |            1 |\n+-----------+--------------+\n\nSELECT v LIKE \'Maria\',v LIKE \'Maria   \' FROM strtest;\n+----------------+-------------------+\n| v LIKE \'Maria\' | v LIKE \'Maria   \' |\n+----------------+-------------------+\n|              0 |                 1 |\n+----------------+-------------------+\n\nTruncation\n----------\n\n* Depending on whether or not strict sql mode is set, you will either get a\nwarning or an error if you try to insert a string that is too long into a\nVARCHAR column. If the extra characters are spaces, the spaces that can\'t fit\nwill be removed and you will always get a warning, regardless of the sql mode\nsetting.\n\nDifference Between VARCHAR and TEXT\n-----------------------------------\n\n* VARCHAR columns can be fully indexed. TEXT columns can only be indexed over\na specified length.\n* Using TEXT or BLOB in a SELECT query that uses temporary tables for storing\nintermediate results will force the temporary table to be disk based (using\nthe Aria storage engine instead of the memory storage engine, which is a bit\nslower. This is not that bad as the Aria storage engine caches the rows in\nmemory. To get the benefit of this, one should ensure that the\naria_pagecache_buffer_size variable is big enough to hold most of the row and\nindex data for temporary tables.\n\nOracle Mode\n-----------\n\nMariaDB starting with 10.3\n--------------------------\nIn Oracle mode from MariaDB 10.3, VARCHAR2 is a synonym.\n\nFor Storage Engine Developers\n-----------------------------\n\n* Internally the full length of the VARCHAR column is allocated inside each\nTABLE objects record[] structure. As there are three such buffers, each open\ntable will allocate 3 times max-length-to-store-varchar bytes of memory.\n* TEXT and BLOB columns are stored with a pointer (4 or 8 bytes) + a 1-4 bytes\nlength.  The TEXT data is only stored once. This means that internally TEXT\nuses less memory for each open table but instead has the additional overhead\nthat each TEXT object needs to be allocated and freed for each row access\n(with some caching in between).\n\nURL: https://mariadb.com/kb/en/varchar/','','https://mariadb.com/kb/en/varchar/'),
(295,'YEAR Data Type',23,'Syntax\n------\n\nYEAR[(4)]\n\nDescription\n-----------\n\nA year in two-digit or four-digit format. The default is four-digit format.\nNote that the two-digit format has been deprecated since MariaDB 5.5.27.\n\nIn four-digit format, the allowable values are 1901 to 2155, and 0000. In\ntwo-digit format, the allowable values are 70 to 69, representing years from\n1970 to 2069. MariaDB displays YEAR values in YYYY format, but allows you to\nassign values to YEAR columns using either strings or numbers.\n\nInserting numeric zero has a different result for YEAR(4) and YEAR(2). For\nYEAR(2), the value 00 reflects the year 2000. For YEAR(4), the value 0000\nreflects the year zero. This only applies to numeric zero. String zero always\nreflects the year 2000.\n\nExamples\n--------\n\nAccepting a string or a number:\n\nCREATE TABLE y(y YEAR);\n\nINSERT INTO y VALUES (1990),(\'2012\');\n\nSELECT * FROM y;\n+------+\n| y    |\n+------+\n| 1990 |\n| 2012 |\n+------+\n\nWith strict_mode set, the default from MariaDB 10.2.4:\n\nOut of range:\n\nINSERT INTO y VALUES (1005),(\'3080\');\nERROR 1264 (22003): Out of range value for column \'y\' at row 1\n\nINSERT INTO y VALUES (\'2013-12-12\');\nERROR 1265 (01000): Data truncated for column \'y\' at row 1\n\nSELECT * FROM y;\n+------+\n| y    |\n+------+\n| 1990 |\n| 2012 |\n+------+\n\nWith strict_mode unset, the default until MariaDB 10.2.3:\n\nOut of range:\n\nINSERT INTO y VALUES (1005),(\'3080\');\nQuery OK, 2 rows affected, 2 warnings (0.05 sec)\nRecords: 2  Duplicates: 0  Warnings: 2\n\nSHOW WARNINGS;\n+---------+------+--------------------------------------------+\n| Level   | Code | Message                                    |\n+---------+------+--------------------------------------------+\n| Warning | 1264 | Out of range value for column \'y\' at row 1 |\n| Warning | 1264 | Out of range value for column \'y\' at row 2 |\n+---------+------+--------------------------------------------+\n\nSELECT * FROM y;\n+------+\n| y    |\n+------+\n| 1990 |\n| 2012 |\n| 0000 |\n| 0000 |\n+------+\n\nTruncating:\n\nINSERT INTO y VALUES (\'2013-12-12\');\nQuery OK, 1 row affected, 1 warning (0.05 sec)\n\nSHOW WARNINGS;\n+---------+------+----------------------------------------+\n| Level   | Code | Message                                |\n+---------+------+----------------------------------------+\n| Warning | 1265 | Data truncated for column \'y\' at row 1 |\n+---------+------+----------------------------------------+\n\nSELECT * FROM y;\n+------+\n| y    |\n+------+\n| 1990 |\n| 2012 |\n| 0000 |\n| 0000 |\n| 2013 |\n+------+\n\nDifference between YEAR(2) and YEAR(4), and string and numeric zero:\n\nCREATE TABLE y2(y YEAR(4), y2 YEAR(2));\nQuery OK, 0 rows affected, 1 warning (0.40 sec)\n\nNote (Code 1287): \'YEAR(2)\' is deprecated and will be removed in a future\nrelease. \n Please use YEAR(4) instead\n\nINSERT INTO y2 VALUES(0,0),(\'0\',\'0\');\n\nSELECT YEAR(y),YEAR(y2) FROM y2;\n+---------+----------+\n| YEAR(y) | YEAR(y2) |\n+---------+----------+\n|       0 |     2000 |\n|    2000 |     2000 |\n+---------+----------+\n\nURL: https://mariadb.com/kb/en/year-data-type/','','https://mariadb.com/kb/en/year-data-type/'),
(290,'UUID Data Type',23,'MariaDB starting with 10.7.0\n----------------------------\nThe UUID data type was added in a MariaDB 10.7.0 preview.\n\nSyntax\n------\n\nUUID\n\nDescription\n-----------\n\nThe UUID data type is intended for the storage of 128-bit UUID (Universally\nUnique Identifier) data. See the UUID function page for more details on UUIDs\nthemselves.\n\nRetrieval\n---------\n\nData retrieved by this data type is in the string representation defined in\nRFC4122.\n\nCasting\n-------\n\nString literals of hexadecimal characters and CHAR/VARCHAR/TEXT can be cast to\nthe UUID data type. Likewise hexadecimal literals, binary-literals, and\nBINARY/VARBINARY/BLOB types can also be cast to UUID.\n\nThe data type will not accept a short UUID generated with the UUID_SHORT\nfunction, but will accept a value without the - character generated by the\nSYS_GUID function (or inserted directly). Hyphens can be partially omitted as\nwell, or included after any group of two digits.\n\nThe type does not accept UUIDs in braces, permitted by some implementations.\n\nStorage\n-------\n\nUUID are stored in an index friendly manner, the order of a UUID of\nllllllll-mmmm-Vhhh-vsss-nnnnnnnnnnnn is stored as:\n\nnnnnnnnnnnnn-vsss-Vhhh-mmmm-llllllll\n\nThis provides a sorting order, if a UUIDv1 (node and timestamp) is used, of\nthe node, followed by the timestamp.\n\nExamples\n--------\n\nCREATE TABLE t1 (id UUID);\n\nDirectly Inserting via string literals:\n\nINSERT INTO t1 VALUES(\'123e4567-e89b-12d3-a456-426655440000\');\n\nDirectly Inserting via hexadecimal literals:\n\nINSERT INTO t1 VALUES (x\'fffffffffffffffffffffffffffffffe\');\n\nGenerating and inserting via the UUID function.\n\nINSERT INTO t1 VALUES (UUID());\n\nRetrieval:\n\nSELECT * FROM t1;\n+--------------------------------------+\n| id                                   |\n+--------------------------------------+\n| 123e4567-e89b-12d3-a456-426655440000 |\n| ffffffff-ffff-ffff-ffff-fffffffffffe |\n| 93aac041-1a14-11ec-ab4e-f859713e4be4 |\n+--------------------------------------+\n\nThe UUID_SHORT function does not generate valid full-length UUID:\n\nINSERT INTO t1 VALUES (UUID_SHORT());\nERROR 1292 (22007): Incorrect uuid value: \'99440417627439104\' \n for column `test`.`t1`.`id` at row 1\n\nAccepting a value without the - character, either directly or generated by the\nSYS_GUID function:\n\nINSERT INTO t1 VALUES (SYS_GUID());\n\nSELECT * FROM t1;\n+--------------------------------------+\n| id                                   |\n+--------------------------------------+\n| 123e4567-e89b-12d3-a456-426655440000 |\n| ffffffff-ffff-ffff-ffff-fffffffffffe |\n| 93aac041-1a14-11ec-ab4e-f859713e4be4 |\n| ea0368d3-1a14-11ec-ab4e-f859713e4be4 |\n+--------------------------------------+\n\nSELECT SYS_GUID();\n+----------------------------------+\n| SYS_GUID()                       |\n+----------------------------------+\n| ff5b6bcc1a1411ecab4ef859713e4be4 |\n+----------------------------------+\n\nINSERT INTO t1 VALUES (\'ff5b6bcc1a1411ecab4ef859713e4be4\');\n\nSELECT * FROM t1;\n+--------------------------------------+\n| id                                   |\n+--------------------------------------+\n| 123e4567-e89b-12d3-a456-426655440000 |\n| ffffffff-ffff-ffff-ffff-fffffffffffe |\n| 93aac041-1a14-11ec-ab4e-f859713e4be4 |\n| ea0368d3-1a14-11ec-ab4e-f859713e4be4 |\n| ff5b6bcc-1a14-11ec-ab4e-f859713e4be4 |\n+--------------------------------------+\n\nValid and invalid hyphen and brace usage:\n\nTRUNCATE t1;\n\nINSERT INTO t1 VALUES (\'f8aa-ed66-1a1b-11ec-ab4e-f859-713e-4be4\');\n\nINSERT INTO t1 VALUES (\'1b80667f1a1c-11ecab4ef859713e4be4\');\n\nINSERT INTO t1 VALUES (\'2fd6c945-1a-1c-11ec-ab4e-f859713e4be4\');\n\nINSERT INTO t1 VALUES (\'49-c9-f9-59-1a-1c-11ec-ab4e-f859713e4be4\');\n\nINSERT INTO t1 VALUES (\'57-96-da-c1-1a-1c-11-ec-ab-4e-f8-59-71-3e-4b-e4\');\n\nINSERT INTO t1 VALUES (\'6-eb74f8f-1a1c-11ec-ab4e-f859713e4be4\');\n\nINSERT INTO t1 VALUES (\'{29bad136-1a1d-11ec-ab4e-f859713e4be4}\');\nERROR 1292 (22007): Incorrect uuid value:\n\'{29bad136-1a1d-11ec-ab4e-f859713e4be4}\' \n for column `test`.`t1`.`id` at row 1\n\nSELECT * FROM t1;\n+--------------------------------------+\n| id                                   |\n+--------------------------------------+\n| f8aaed66-1a1b-11ec-ab4e-f859713e4be4 |\n| 1b80667f-1a1c-11ec-ab4e-f859713e4be4 |\n| 2fd6c945-1a1c-11ec-ab4e-f859713e4be4 |\n| 49c9f959-1a1c-11ec-ab4e-f859713e4be4 |\n| 5796dac1-1a1c-11ec-ab4e-f859713e4be4 |\n| 6eb74f8f-1a1c-11ec-ab4e-f859713e4be4 |\n+--------------------------------------+\n\nURL: https://mariadb.com/kb/en/uuid-data-type/','','https://mariadb.com/kb/en/uuid-data-type/'),
(297,'Using Compound Statements Outside of Stored Programs',24,'Compound statements can also be used outside of stored programs.\n\ndelimiter |\nIF @have_innodb THEN\n CREATE TABLE IF NOT EXISTS innodb_index_stats (\n  database_name    VARCHAR(64) NOT NULL,\n  table_name       VARCHAR(64) NOT NULL,\n  index_name       VARCHAR(64) NOT NULL,\n  last_update      TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE\nCURRENT_TIMESTAMP,\n  stat_name        VARCHAR(64) NOT NULL,\n  stat_value       BIGINT UNSIGNED NOT NULL,\n  sample_size      BIGINT UNSIGNED,\n  stat_description VARCHAR(1024) NOT NULL,\n  PRIMARY KEY (database_name, table_name, index_name, stat_name)\n ) ENGINE=INNODB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0;\nEND IF|\nQuery OK, 0 rows affected, 2 warnings (0.00 sec)\n\nNote, that using compound statements this way is subject to following\nlimitations:\n\n* Only BEGIN, IF, CASE, LOOP, WHILE, REPEAT statements may start a compound\nstatement outside of stored programs.\n* BEGIN must use the BEGIN NOT ATOMIC syntax (otherwise it\'ll be confused with\nBEGIN that starts a transaction).\n* A compound statement might not start with a label.\n* A compound statement is parsed completely—note \"2 warnings\" in the above\nexample, even if the condition was false (InnoDB was, indeed, disabled), and\nthe CREATE TABLE statement was not executed, it was still parsed and the\nparser produced \"Unknown storage engine\" warning.\n\nInside a compound block first three limitations do not apply, one can use\nanything that can be used inside a stored program — including labels,\ncondition handlers, variables, and so on:\n\nBEGIN NOT ATOMIC\n  DECLARE foo CONDITION FOR 1146;\n  DECLARE x INT DEFAULT 0;\n  DECLARE CONTINUE HANDLER FOR SET x=1;\n  INSERT INTO test.t1 VALUES (\"hndlr1\", val, 2);\n  END|\n\nExample how to use IF:\n\nIF (1>0) THEN BEGIN NOT ATOMIC SELECT 1; END ; END IF;;\n\nExample of how to use WHILE loop:\n\nDELIMITER |\nBEGIN NOT ATOMIC\n  DECLARE x INT DEFAULT 0;\n  WHILE x <= 10 DO\n    SET x = x + 1;\n    SELECT x;\n  END WHILE;\nEND|\nDELIMITER ;\n\nURL:\nhttps://mariadb.com/kb/en/using-compound-statements-outside-of-stored-programs/','','https://mariadb.com/kb/en/using-compound-statements-outside-of-stored-programs/'),
(728,'DROP PACKAGE BODY',38,'MariaDB starting with 10.3.5\n----------------------------\nOracle-style packages were introduced in MariaDB 10.3.5.\n\nSyntax\n------\n\nDROP PACKAGE BODY [IF EXISTS]  [ db_name . ] package_name\n\nDescription\n-----------\n\nThe DROP PACKAGE BODY statement can be used when Oracle SQL_MODE is set.\n\nThe DROP PACKAGE BODY statement drops the package body (i.e the\nimplementation), previously created using the CREATE PACKAGE BODY statement.\n\nNote, DROP PACKAGE BODY drops only the package implementation, but does not\ndrop the package specification. Use DROP PACKAGE to drop the package entirely\n(i.e. both implementation and specification).\n\nURL: https://mariadb.com/kb/en/drop-package-body/','','https://mariadb.com/kb/en/drop-package-body/'),
(292,'TIME',23,'Syntax\n------\n\nTIME [(<microsecond precision>)]\n\nDescription\n-----------\n\nA time. The range is \'-838:59:59.999999\' to \'838:59:59.999999\'. Microsecond\nprecision can be from 0-6; if not specified 0 is used. Microseconds have been\navailable since MariaDB 5.3.\n\nMariaDB displays TIME values in \'HH:MM:SS.ssssss\' format, but allows\nassignment of times in looser formats, including \'D HH:MM:SS\', \'HH:MM:SS\',\n\'HH:MM\', \'D HH:MM\', \'D HH\', \'SS\', or \'HHMMSS\', as well as permitting dropping\nof any leading zeros when a delimiter is provided, for example \'3:9:10\'. For\ndetails, see date and time literals.\n\nMariaDB 10.1.2 introduced the --mysql56-temporal-format option, on by default,\nwhich allows MariaDB to store TIMEs using the same low-level format MySQL 5.6\nuses.\n\nInternal Format\n---------------\n\nIn MariaDB 10.1.2 a new temporal format was introduced from MySQL 5.6 that\nalters how the TIME, DATETIME and TIMESTAMP columns operate at lower levels.\nThese changes allow these temporal data types to have fractional parts and\nnegative values. You can disable this feature using the\nmysql56_temporal_format system variable.\n\nTables that include TIMESTAMP values that were created on an older version of\nMariaDB or that were created while the mysql56_temporal_format system variable\nwas disabled continue to store data using the older data type format.\n\nIn order to update table columns from the older format to the newer format,\nexecute an ALTER TABLE... MODIFY COLUMN statement that changes the column to\nthe *same* data type. This change may be needed if you want to export the\ntable\'s tablespace and import it onto a server that has\nmysql56_temporal_format=ON set (see MDEV-15225).\n\nFor instance, if you have a TIME column in your table:\n\nSHOW VARIABLES LIKE \'mysql56_temporal_format\';\n\n+-------------------------+-------+\n| Variable_name           | Value |\n+-------------------------+-------+\n| mysql56_temporal_format | ON    |\n+-------------------------+-------+\n\nALTER TABLE example_table MODIFY ts_col TIME;\n\nWhen MariaDB executes the ALTER TABLE statement, it converts the data from the\nolder temporal format to the newer one.\n\nIn the event that you have several tables and columns using temporal data\ntypes that you want to switch over to the new format, make sure the system\nvariable is enabled, then perform a dump and restore using mariadb-dump. The\ncolumns using relevant temporal data types are restored using the new temporal\nformat.\n\nStarting from MariaDB 10.5.1 columns with old temporal formats are marked with\na /* mariadb-5.3 */ comment in the output of SHOW CREATE TABLE, SHOW COLUMNS,\nDESCRIBE statements, as well as in the COLUMN_TYPE column of the\nINFORMATION_SCHEMA.COLUMNS Table.\n\nSHOW CREATE TABLE mariadb5312_time\\G\n*************************** 1. row ***************************\n   Table: mariadb5312_time\nCreate Table: CREATE TABLE `mariadb5312_time` (\n `t0` time /* mariadb-5.3 */ DEFAULT NULL,\n `t6` time(6) /* mariadb-5.3 */ DEFAULT NULL\n) ENGINE=MyISAM DEFAULT CHARSET=latin1\n\nNote, columns with the current format are not marked with a comment.\n\nExamples\n--------\n\nINSERT INTO time VALUES (\'90:00:00\'), (\'800:00:00\'), (800), (22), (151413),\n(\'9:6:3\'), (\'12 09\');\n\nSELECT * FROM time;\n+-----------+\n| t         |\n+-----------+\n| 90:00:00  |\n| 800:00:00 |\n| 00:08:00  |\n| 00:00:22  |\n| 15:14:13  |\n| 09:06:03  |\n| 297:00:00 |\n+-----------+\n\nURL: https://mariadb.com/kb/en/time/','','https://mariadb.com/kb/en/time/'),
(298,'BEGIN END',24,'Syntax\n------\n\n[begin_label:] BEGIN [NOT ATOMIC]\n  [statement_list]\nEND [end_label]\n\nNOT ATOMIC is required when used outside of a stored procedure. Inside stored\nprocedures or within an anonymous block, BEGIN alone starts a new anonymous\nblock.\n\nDescription\n-----------\n\nBEGIN ... END syntax is used for writing compound statements. A compound\nstatement can contain multiple statements, enclosed by the BEGIN and END\nkeywords. statement_list represents a list of one or more statements, each\nterminated by a semicolon (i.e., ;) statement delimiter. statement_list is\noptional, which means that the empty compound statement (BEGIN END) is legal.\n\nNote that END will perform a commit. If you are running in autocommit mode,\nevery statement will be committed separately. If you are not running in\nautocommit mode, you must execute a COMMIT or ROLLBACK after END to get the\ndatabase up to date.\n\nUse of multiple statements requires that a client is able to send statement\nstrings containing the ; statement delimiter. This is handled in the mysql\ncommand-line client with the DELIMITER command. Changing the ;\nend-of-statement delimiter (for example, to //) allows ; to be used in a\nprogram body.\n\nA compound statement within a stored program can be labeled. end_label cannot\nbe given unless begin_label also is present. If both are present, they must be\nthe same.\n\nBEGIN ... END constructs can be nested. Each block can define its own\nvariables, a CONDITION, a HANDLER and a CURSOR, which don\'t exist in the outer\nblocks. The most local declarations override the outer objects which use the\nsame name (see example below).\n\nThe declarations order is the following:\n\n* DECLARE local variables;\n* DECLARE CONDITIONs;\n* DECLARE CURSORs;\n* DECLARE HANDLERs;\n\nNote that DECLARE HANDLER contains another BEGIN ... END construct.\n\nHere is an example of a very simple, anonymous block:\n\nBEGIN NOT ATOMIC\nSET @a=1;\nCREATE TABLE test.t1(a INT);\nEND|\n\nBelow is an example of nested blocks in a stored procedure:\n\nCREATE PROCEDURE t( )\nBEGIN\n DECLARE x TINYINT UNSIGNED DEFAULT 1;\n BEGIN\n   DECLARE x CHAR(2) DEFAULT \'02\';\n   DECLARE y TINYINT UNSIGNED DEFAULT 10;\n   SELECT x, y;\n END;\n SELECT x;\nEND;\n\nIn this example, a TINYINT variable, x is declared in the outter block. But in\nthe inner block x is re-declared as a CHAR and an y variable is declared. The\ninner SELECT shows the \"new\" value of x, and the value of y. But when x is\nselected in the outer block, the \"old\" value is returned. The final SELECT\ndoesn\'t try to read y, because it doesn\'t exist in that context.\n\nURL: https://mariadb.com/kb/en/begin-end/','','https://mariadb.com/kb/en/begin-end/'),
(731,'DROP TABLESPACE',38,'The DROP TABLESPACE statement is not supported by MariaDB. It was originally\ninherited from MySQL NDB Cluster. In MySQL 5.7 and later, the statement is\nalso supported for InnoDB. However, MariaDB has chosen not to include that\nspecific feature. See MDEV-19294 for more information.\n\nURL: https://mariadb.com/kb/en/drop-tablespace/','','https://mariadb.com/kb/en/drop-tablespace/'),
(735,'Dynamic Columns',38,'Dynamic columns allow one to store different sets of columns for each row in a\ntable. It works by storing a set of columns in a blob and having a small set\nof functions to manipulate it. Dynamic columns should be used when it is not\npossible to use regular columns. A typical use case is when one needs to store\nitems that may have many different attributes (like size, color, weight, etc),\nand the set of possible attributes is very large and/or unknown in advance. In\nthat case, attributes can be put into dynamic columns.\n\nDynamic Columns Basics\n----------------------\n\nThe table should have a blob column which will be used as storage for dynamic\ncolumns:\n\ncreate table assets (\n item_name varchar(32) primary key, -- A common attribute for all items\n dynamic_cols  blob  -- Dynamic columns will be stored here\n);\n\nOnce created, one can access dynamic columns via dynamic column functions:\n\nInsert a row with two dynamic columns: color=blue, size=XL\n\nINSERT INTO assets VALUES \n (\'MariaDB T-shirt\', COLUMN_CREATE(\'color\', \'blue\', \'size\', \'XL\'));\n\nInsert another row with dynamic columns: color=black, price=500\n\nINSERT INTO assets VALUES\n (\'Thinkpad Laptop\', COLUMN_CREATE(\'color\', \'black\', \'price\', 500));\n\nSelect dynamic column \'color\' for all items:\n\nSELECT item_name, COLUMN_GET(dynamic_cols, \'color\' as char) \n AS color FROM assets;\n+-----------------+-------+\n| item_name       | color |\n+-----------------+-------+\n| MariaDB T-shirt | blue  |\n| Thinkpad Laptop | black |\n+-----------------+-------+\n\nIt is possible to add and remove dynamic columns from a row:\n\n-- Remove a column:\nUPDATE assets SET dynamic_cols=COLUMN_DELETE(dynamic_cols, \"price\") \nWHERE COLUMN_GET(dynamic_cols, \'color\' as char)=\'black\';\n\n-- Add a column:\nUPDATE assets SET dynamic_cols=COLUMN_ADD(dynamic_cols, \'warranty\', \'3 years\')\nWHERE item_name=\'Thinkpad Laptop\';\n\nYou can also list all columns, or get them together with their values in JSON\nformat:\n\nSELECT item_name, column_list(dynamic_cols) FROM assets;\n+-----------------+---------------------------+\n| item_name       | column_list(dynamic_cols) |\n+-----------------+---------------------------+\n| MariaDB T-shirt | `size`,`color`            |\n| Thinkpad Laptop | `color`,`warranty`        |\n+-----------------+---------------------------+\n\nSELECT item_name, COLUMN_JSON(dynamic_cols) FROM assets;\n+-----------------+----------------------------------------+\n| item_name       | COLUMN_JSON(dynamic_cols)              |\n+-----------------+----------------------------------------+\n| MariaDB T-shirt | {\"size\":\"XL\",\"color\":\"blue\"}           |\n| Thinkpad Laptop | {\"color\":\"black\",\"warranty\":\"3 years\"} |\n+-----------------+----------------------------------------+\n\nDynamic Columns Reference\n-------------------------\n\nThe rest of this page is a complete reference of dynamic columns in MariaDB\n\nDynamic Columns Functions\n-------------------------\n\nCOLUMN_CREATE\n-------------\n\nCOLUMN_CREATE(column_nr, value [as type], [column_nr, value \n [as type]]...);\nCOLUMN_CREATE(column_name, value [as type], [column_name, value \n [as type]]...);\n\nReturn a dynamic columns blob that stores the specified columns with values.\n\nThe return value is suitable for\n\n* \nstoring in a table\nfurther modification with other dynamic columns functions\n\nThe as type part allows one to specify the value type. In most cases, this is\nredundant because MariaDB will be able to deduce the type of the value.\nExplicit type specification may be needed when the type of the value is not\napparent. For example, a literal \'2012-12-01\' has a CHAR type by default, one\nwill need to specify \'2012-12-01\' AS DATE to have it stored as a date. See the\nDatatypes section for further details. Note also MDEV-597.\n\nTypical usage:\n\n-- MariaDB 5.3+:\nINSERT INTO tbl SET dyncol_blob=COLUMN_CREATE(1 /*column id*/, \"value\");\n-- MariaDB 10.0.1+:\nINSERT INTO tbl SET dyncol_blob=COLUMN_CREATE(\"column_name\", \"value\");\n\nCOLUMN_ADD\n----------\n\nCOLUMN_ADD(dyncol_blob, column_nr, value [as type], \n [column_nr, value [as type]]...);\nCOLUMN_ADD(dyncol_blob, column_name, value [as type], \n [column_name, value [as type]]...);\n\nAdds or updates dynamic columns.\n\n* \ndyncol_blob must be either a valid dynamic columns blob (for example,\nCOLUMN_CREATE returns such blob), or an empty string.\ncolumn_name specifies the name of the column to be added. If dyncol_blob\nalready has a column with this name, it will be overwritten.\nvalue specifies the new value for the column.  Passing a NULL value will cause\nthe column to be deleted.\nas type is optional. See #datatypes section for a discussion about types.\n\nThe return value is a dynamic column blob after the modifications.\n\nTypical usage:\n\n-- MariaDB 5.3+:\nUPDATE tbl SET dyncol_blob=COLUMN_ADD(dyncol_blob, 1 /*column id*/, \"value\") \n WHERE id=1;\n-- MariaDB 10.0.1+:\nUPDATE t1 SET dyncol_blob=COLUMN_ADD(dyncol_blob, \"column_name\", \"value\") \n WHERE id=1;\n\nNote: COLUMN_ADD() is a regular function (just like CONCAT()), hence, in order\nto update the value in the table you have to use the UPDATE ... SET\ndynamic_col=COLUMN_ADD(dynamic_col, ....) pattern.\n\nCOLUMN_GET\n----------\n\nCOLUMN_GET(dyncol_blob, column_nr as type);\nCOLUMN_GET(dyncol_blob, column_name as type);\n\nGet the value of a dynamic column by its name. If no column with the given\nname exists, NULL will be returned.\n\ncolumn_name as type requires that one specify the datatype of the dynamic\ncolumn they are reading.\n\nThis may seem counter-intuitive: why would one need to specify which datatype\nthey\'re retrieving? Can\'t the dynamic columns system figure the datatype from\nthe data being stored?\n\nThe answer is: SQL is a statically-typed language. The SQL interpreter needs\nto know the datatypes of all expressions before the query is run (for example,\nwhen one is using prepared statements and runs \"select COLUMN_GET(...)\", the\nprepared statement API requires the server to inform the client about the\ndatatype of the column being read before the query is executed and the server\ncan see what datatype the column actually has).\n\nSee the Datatypes section for more information about datatypes.\n\nCOLUMN_DELETE\n-------------\n\nCOLUMN_DELETE(dyncol_blob, column_nr, column_nr...);\nCOLUMN_DELETE(dyncol_blob, column_name, column_name...);\n\nDelete a dynamic column with the specified name. Multiple names can be given.\n\nThe return value is a dynamic column blob after the modification.\n\nCOLUMN_EXISTS\n-------------\n\nCOLUMN_EXISTS(dyncol_blob, column_nr);\nCOLUMN_EXISTS(dyncol_blob, column_name);\n\nCheck if a column with name column_name exists in dyncol_blob. If yes, return\n1, otherwise return 0.\n\nCOLUMN_LIST\n-----------\n\nCOLUMN_LIST(dyncol_blob);\n\nReturn a comma-separated list of column names. The names are quoted with\nbackticks.\n\nSELECT column_list(column_create(\'col1\',\'val1\',\'col2\',\'val2\'));\n+---------------------------------------------------------+\n| column_list(column_create(\'col1\',\'val1\',\'col2\',\'val2\')) |\n+---------------------------------------------------------+\n| `col1`,`col2`                                           |\n+---------------------------------------------------------+\n\nCOLUMN_CHECK\n------------\n\nCOLUMN_CHECK(dyncol_blob);\n\nCheck if dyncol_blob is a valid packed dynamic columns blob. Return value of 1\nmeans the blob is valid, return value of 0 means it is not.\n\nRationale: Normally, one works with valid dynamic column blobs. Functions like\nCOLUMN_CREATE, COLUMN_ADD, COLUMN_DELETE always return valid dynamic column\nblobs. However, if a dynamic column blob is accidentally truncated, or\ntranscoded from one character set to another, it will be corrupted. This\nfunction can be used to check if a value in a blob field is a valid dynamic\ncolumn blob.\n\nNote: It is possible that a truncation cut a Dynamic Column \"clearly\" so that\nCOLUMN_CHECK will not notice the corruption, but in any case of truncation a\nwarning is issued during value storing.\n\nCOLUMN_JSON\n-----------\n\nCOLUMN_JSON(dyncol_blob);\n\nReturn a JSON representation of data in dyncol_blob.\n\nExample:\n\nSELECT item_name, COLUMN_JSON(dynamic_cols) FROM assets;\n+-----------------+----------------------------------------+\n| item_name       | COLUMN_JSON(dynamic_cols)              |\n+-----------------+----------------------------------------+\n| MariaDB T-shirt | {\"size\":\"XL\",\"color\":\"blue\"}           |\n| Thinkpad Laptop | {\"color\":\"black\",\"warranty\":\"3 years\"} |\n+-----------------+----------------------------------------+\n\nLimitation: COLUMN_JSON will decode nested dynamic columns at a nesting level\nof not more than 10 levels deep. Dynamic columns that are nested deeper than\n10 levels will be shown as BINARY string, without encoding.\n\nNesting Dynamic Columns\n-----------------------\n\nIt is possible to use nested dynamic columns by putting one dynamic column\nblob inside another. The COLUMN_JSON function will display nested columns.\n\nSET @tmp= column_create(\'parent_column\', \n column_create(\'child_column\', 12345));\nQuery OK, 0 rows affected (0.00 sec)\n\nSELECT column_json(@tmp);\n+------------------------------------------+\n| column_json(@tmp)                        |\n+------------------------------------------+\n| {\"parent_column\":{\"child_column\":12345}} |\n+------------------------------------------+\n\nSELECT column_get(column_get(@tmp, \'parent_column\' AS char), \n \'child_column\' AS int);\n+------------------------------------------------------------------------------\n\n| column_get(column_get(@tmp, \'parent_column\' as char), \'child_column\' as int)\n|\n+------------------------------------------------------------------------------\n\n|                                                                        12345\n|\n+------------------------------------------------------------------------------\n\nIf you are trying to get a nested dynamic column as a string use \'as BINARY\'\nas the last argument of COLUMN_GET (otherwise problems with character set\nconversion and illegal symbols are possible):\n\nselect column_json( column_get(\n column_create(\'test1\',\n  column_create(\'key1\',\'value1\',\'key2\',\'value2\',\'key3\',\'value3\')),\n \'test1\' as BINARY));\n\nDatatypes\n---------\n\nIn SQL, one needs to define the type of each column in a table. Dynamic\ncolumns do not provide any way to declare a type in advance (\"whenever there\nis a column \'weight\', it should be integer\" is not possible). However, each\nparticular dynamic column value is stored together with its datatype.\n\nThe set of possible datatypes is mostly the same as that used by the SQL CAST\nand CONVERT functions. However, note that there are currently some differences\n- see MDEV-597.\n\n+--------+----------------------------------------------+-------------------+\n| type   | dynamic column internal type                 | description       |\n+--------+----------------------------------------------+-------------------+\n| BINARY | DYN_COL_STRING                               | (variable length  |\n| (N)]   |                                              | string with       |\n|        |                                              | binary charset)   |\n+--------+----------------------------------------------+-------------------+\n| CHAR[( | DYN_COL_STRING                               | (variable length  |\n| )]     |                                              | string with       |\n|        |                                              | charset)          |\n+--------+----------------------------------------------+-------------------+\n| DATE   | DYN_COL_DATE                                 | (date - 3 bytes)  |\n+--------+----------------------------------------------+-------------------+\n| DATETI | DYN_COL_DATETIME                             | (date and time    |\n| E[(D)] |                                              | (with             |\n|        |                                              | microseconds) -   |\n|        |                                              | 9 bytes)          |\n+--------+----------------------------------------------+-------------------+\n| DECIMA | DYN_COL_DECIMAL                              | (variable length  |\n| [(M[,D |                                              | binary decimal    |\n| )]     |                                              | representation    |\n|        |                                              | with MariaDB      |\n|        |                                              | limitation)       |\n+--------+----------------------------------------------+-------------------+\n| DOUBLE | DYN_COL_DOUBLE                               | (64 bit           |\n| (M,D)] |                                              | double-precision  |\n|        |                                              | floating point)   |\n+--------+----------------------------------------------+-------------------+\n| INTEGE | DYN_COL_INT                                  | (variable         |\n|        |                                              | length, up to 64  |\n|        |                                              | bit signed        |\n|        |                                              | integer)          |\n+--------+----------------------------------------------+-------------------+\n| SIGNED | DYN_COL_INT                                  | (variable         |\n| [INTEG |                                              | length, up to 64  |\n| R]     |                                              | bit signed        |\n|        |                                              | integer)          |\n+--------+----------------------------------------------+-------------------+\n| TIME[( | DYN_COL_TIME                                 | (time (with       |\n| )]     |                                              | microseconds,     |\n|        |                                              | may be negative)  |\n|        |                                              | - 6 bytes)        |\n+--------+----------------------------------------------+-------------------+\n| UNSIGN | DYN_COL_UINT                                 | (variable         |\n| D      |                                              | length, up to     |\n| [INTEG |                                              | 64bit unsigned    |\n| R]     |                                              | integer)          |\n+--------+----------------------------------------------+-------------------+\n\nA Note About Lengths\n--------------------\n\nIf you\'re running queries like\n\nSELECT COLUMN_GET(blob, \'colname\' as CHAR) ...\n\nwithout specifying a maximum length (i.e. using #as CHAR#, not as CHAR(n)),\nMariaDB will report the maximum length of the resultset column to be\n53,6870,911 (bytes or characters?) for MariaDB 5.3-10.0.0 and 16,777,216 for\nMariaDB 10.0.1+. This may cause excessive memory usage in some client\nlibraries, because they try to pre-allocate a buffer of maximum resultset\nwidth. If you suspect you\'re hitting this problem, use CHAR(n) whenever you\'re\nusing COLUMN_GET in the select list.\n\nMariaDB 5.3 vs MariaDB 10.0\n---------------------------\n\nThe dynamic columns feature was introduced into MariaDB in two steps:\n\n* MariaDB 5.3 was the first version to support dynamic columns. Only numbers\n could be used as column names in this version.\n* In MariaDB 10.0.1, column names can be either numbers or strings.\n Also, the COLUMN_JSON and COLUMN_CHECK functions were added.\n\nSee also Dynamic Columns in MariaDB 10.\n\nClient-side API\n---------------\n\nIt is also possible to create or parse dynamic columns blobs on the client\nside. libmysql client library now includes an API for writing/reading dynamic\ncolumn blobs. See dynamic-columns-api for details.\n\nLimitations\n-----------\n\n+---------------------------------------------------+------------------------+\n| Description                                       | Limit                  |\n+---------------------------------------------------+------------------------+\n| Max number of columns                             | 65535                  |\n+---------------------------------------------------+------------------------+\n| Max total length of packed dynamic column         | max_allowed_packet     |\n|                                                   | (1G)                   |\n+---------------------------------------------------+------------------------+\n\nURL: https://mariadb.com/kb/en/dynamic-columns/','','https://mariadb.com/kb/en/dynamic-columns/'),
(738,'Sequence Overview',39,'This page is about sequence objects. For details about the storage engine, see\nSequence Storage Engine.\n\nIntroduction\n------------\n\nA sequence is an object that generates a sequence of numeric values, as\nspecified by the CREATE SEQUENCE statement.\n\nCREATE SEQUENCE will create a sequence that generates new values when called\nwith NEXT VALUE FOR sequence_name. It\'s an alternative to AUTO INCREMENT when\none wants to have more control of how the numbers are generated. As the\nSEQUENCE caches values (up to the CACHE value in the CREATE SEQUENCE\nstatement, by default 1000) it can in some cases be much faster than AUTO\nINCREMENT. Another benefit is that one can access the last value generated by\nall used sequences, which solves one of the limitations with LAST_INSERT_ID().\n\nCreating a Sequence\n-------------------\n\nThe CREATE SEQUENCE statement is used to create a sequence. Here is an example\nof a sequence starting at 100, incrementing by 10 each time:\n\nCREATE SEQUENCE s START WITH 100 INCREMENT BY 10;\n\nThe CREATE SEQUENCE statement, along with defaults, can be viewd with the SHOW\nCREATE SEQUENCE STATEMENT, for example:\n\nSHOW CREATE SEQUENCE s\\G\n*************************** 1. row ***************************\n   Table: s\nCreate Table: CREATE SEQUENCE `s` start with 100 minvalue 1 maxvalue\n9223372036854775806 \n increment by 10 cache 1000 nocycle ENGINE=InnoDB\n\nUsing Sequence Objects\n----------------------\n\nTo get the next value from a sequence, use\n\nNEXT VALUE FOR sequence_name\n\nor\n\nNEXTVAL(sequence_name)\n\nor in Oracle mode (SQL_MODE=ORACLE)\n\nsequence_name.nextval\n\nFor retrieving the last value used by the current connection from a sequence\nuse:\n\nPREVIOUS VALUE FOR sequence_name\n\nor\n\nLASTVAL(sequence_name)\n\nor in Oracle mode (SQL_MODE=ORACLE)\n\nsequence_name.currval\n\nFor example:\n\nSELECT NEXTVAL(s);\n+------------+\n| NEXTVAL(s) |\n+------------+\n|        100 |\n+------------+\n\nSELECT NEXTVAL(s);\n+------------+\n| NEXTVAL(s) |\n+------------+\n|        110 |\n+------------+\n\nSELECT LASTVAL(s);\n+------------+\n| LASTVAL(s) |\n+------------+\n|        110 |\n+------------+\n\nUsing Sequences in DEFAULT\n--------------------------\n\nSequences can be used in DEFAULT:\n\ncreate sequence s1;\ncreate table t1 (a int primary key default (next value for s1), b int);\ninsert into t1 (b) values (1),(2);\nselect * from t1;\n+---+------+\n| a | b    |\n+---+------+\n| 1 |    1 |\n| 2 |    2 |\n+---+------+\n\nChanging a Sequence\n-------------------\n\nThe ALTER SEQUENCE statement is used for changing sequences. For example, to\nrestart the sequence at another value:\n\nALTER SEQUENCE s RESTART 50;\n\nSELECT NEXTVAL(s);\n+------------+\n| NEXTVAL(s) |\n+------------+\n|         50 |\n+------------+\n\nThe SETVAL function can also be used to set the next value to be returned for\na SEQUENCE, for example:\n\nSELECT SETVAL(s, 100);\n+----------------+\n| SETVAL(s, 100) |\n+----------------+\n|            100 |\n+----------------+\n\nSETVAL can only be used to increase the sequence value. Attempting to set a\nlower value will fail, returning NULL:\n\nSELECT SETVAL(s, 50);\n+---------------+\n| SETVAL(s, 50) |\n+---------------+\n|          NULL |\n+---------------+\n\nDropping a Sequence\n-------------------\n\nThe DROP SEQUENCE statement is used to drop a sequence, for example:\n\nDROP SEQUENCE s;\n\nReplication\n-----------\n\nIf one wants to use Sequences in a master-master setup or with Galera one\nshould use INCREMENT=0. This will tell the Sequence to use\nauto_increment_increment and auto_increment_offset to generate unique values\nfor each server.\n\nStandards Compliance\n--------------------\n\nMariaDB supports both ANSI SQL and Oracle syntax for sequences.\n\nHowever as SEQUENCE is implemented as a special kind of table, it uses the\nsame namespace as tables. The benefits are that sequences show up in SHOW\nTABLES, and one can also create a sequence with CREATE TABLE and drop it with\nDROP TABLE. One can SELECT from it as from any other table. This ensures that\nall old tools that work with tables should work with sequences.\n\nSince sequence objects act as regular tables in many contexts, they will be\naffected by LOCK TABLES. This is not the case in other DBMS, such as Oracle,\nwhere LOCK TABLE does not affect sequences.\n\nNotes\n-----\n\nOne of the goals with the Sequence implementation is that all old tools, such\nas mariadb-dump (previously mysqldump), should work unchanged, while still\nkeeping the normal usage of sequence standard compatibly.\n\nTo make this possible, sequence is currently implemented as a table with a few\nexclusive properties.\n\nThe special properties for sequence tables are:\n\n* A sequence table has always one row.\n* When one creates a sequence, either with CREATE TABLE or CREATE SEQUENCE,\none row will be inserted.\n* If one tries to insert into a sequence table, the single row will be\nupdated.  This allows mariadb-dump to work but also gives the additional\nbenefit that one can change all properties of a sequence with a single insert.\nNew applications should of course also use ALTER SEQUENCE.\n* UPDATE or DELETE can\'t be performed on Sequence objects.\n* Doing a select on the sequence shows the current state of the sequence,\nexcept the values that are reserved in the cache.  The next_value column shows\nthe next value not reserved by the cache.\n* FLUSH TABLES will close the sequence and the next sequence number generated\nwill be according to what\'s stored in the Sequence object. In effect, this\nwill discard the cached values.\n* A number of normal table operations work on Sequence tables. See next\nsection.\n\nTable Operations that Work with Sequences\n-----------------------------------------\n\n* SHOW CREATE TABLE sequence_name. This shows the table structure that is\nbehind the SEQUENCE including the field names that can be used with SELECT or\neven CREATE TABLE.\n* CREATE TABLE sequence-structure ... SEQUENCE=1\n* ALTER TABLE sequence RENAME TO sequence2\n* RENAME TABLE sequence_name TO new_sequence_name\n* DROP TABLE sequence_name. This is allowed mainly to get old tools like\nmariadb-dump to work with sequence tables.\n* SHOW TABLES\n\nImplementation\n--------------\n\nInternally, sequence tables are created as a normal table without rollback\n(the InnoDB, Aria and MySAM engines support this), wrapped by a sequence\nengine object. This allowed us to create sequences with almost no performance\nimpact for normal tables. (The cost is one \'if\' per insert if the binary log\nis enabled).\n\nUnderlying Table Structure\n--------------------------\n\nThe following example shows the table structure of sequences and how it can be\nused as a table. (Output of results are slightly edited to make them easier to\nread)\n\ncreate sequence t1;\nshow create sequence t1\\G\n*************************** 1. row ***************************\n CREATE SEQUENCE `t1` start with 1 minvalue 1 maxvalue 9223372036854775806\n increment by 1 cache 1000 nocycle ENGINE=InnoDB\n\nshow create table t1\\G\n*************************** 1. row ***************************\nCreate Table: CREATE TABLE `t1` (\n `next_not_cached_value` bigint(21) NOT NULL,\n `minimum_value` bigint(21) NOT NULL,\n `maximum_value` bigint(21) NOT NULL,\n `start_value` bigint(21) NOT NULL COMMENT \'start value when sequences is\ncreated or value if RESTART is used\',\n `increment` bigint(21) NOT NULL COMMENT \'increment value\',\n `cache_size` bigint(21) unsigned NOT NULL,\n `cycle_option` tinyint(1) unsigned NOT NULL COMMENT \'0 if no cycles are\nallowed, 1 if the sequence should begin a new cycle when maximum_value is\npassed\',\n `cycle_count` bigint(21) NOT NULL COMMENT \'How many cycles have been done\'\n) ENGINE=InnoDB SEQUENCE=1\n\nselect * from t1\\G\nnext_not_cached_value: 1\n minimum_value: 1\n maximum_value: 9223372036854775806\n start_value: 1\n increment: 1\n cache_size: 1000\n cycle_option: 0\n cycle_count: 0\n\nThe cycle_count column is incremented every time the sequence wraps around.\n\nCredits\n-------\n\n* Thanks to Jianwe Zhao from Aliyun for his work on SEQUENCE in AliSQL, which\ngave ideas and inspiration for this work.\n* Thanks to Peter Gulutzan,who helped test and gave useful comments about the\nimplementation.\n\nURL: https://mariadb.com/kb/en/sequence-overview/','','https://mariadb.com/kb/en/sequence-overview/'),
(748,'JSON_ARRAY',40,'Syntax\n------\n\nJSON_ARRAY([value[, value2] ...])\n\nDescription\n-----------\n\nReturns a JSON array containing the listed values. The list can be empty.\n\nExample\n-------\n\nSELECT Json_Array(56, 3.1416, \'My name is \"Foo\"\', NULL);\n+--------------------------------------------------+\n| Json_Array(56, 3.1416, \'My name is \"Foo\"\', NULL) |\n+--------------------------------------------------+\n| [56, 3.1416, \"My name is \\\"Foo\\\"\", null]         |\n+--------------------------------------------------+\n\nURL: https://mariadb.com/kb/en/json_array/','','https://mariadb.com/kb/en/json_array/'),
(751,'JSON_COMPACT',40,'Syntax\n------\n\nJSON_COMPACT(json_doc)\n\nDescription\n-----------\n\nRemoves all unnecessary spaces so the json document is as short as possible.\n\nExample\n-------\n\nSET @j = \'{ \"A\": 1, \"B\": [2, 3]}\';\n\nSELECT JSON_COMPACT(@j), @j;\n+-------------------+------------------------+\n| JSON_COMPACT(@j)  | @j                     |\n+-------------------+------------------------+\n| {\"A\":1,\"B\":[2,3]} | { \"A\": 1, \"B\": [2, 3]} |\n+-------------------+------------------------+\n\nURL: https://mariadb.com/kb/en/json_compact/','','https://mariadb.com/kb/en/json_compact/'),
(293,'DATETIME',23,'Syntax\n------\n\nDATETIME [(microsecond precision)]\n\nDescription\n-----------\n\nA date and time combination.\n\nMariaDB displays DATETIME values in \'YYYY-MM-DD HH:MM:SS.ffffff\' format, but\nallows assignment of values to DATETIME columns using either strings or\nnumbers. For details, see date and time literals.\n\nDATETIME columns also accept CURRENT_TIMESTAMP as the default value.\n\nMariaDB 10.1.2 introduced the --mysql56-temporal-format option, on by default,\nwhich allows MariaDB to store DATETMEs using the same low-level format MySQL\n5.6 uses. For more information, see Internal Format, below.\n\nFor storage requirements, see Data Type Storage Requirements.\n\nSupported Values\n----------------\n\nMariaDB stores values that use the DATETIME data type in a format that\nsupports values between 1000-01-01 00:00:00.000000 and 9999-12-31\n23:59:59.999999.\n\nMariaDB can also store microseconds with a precision between 0 and 6. If no\nmicrosecond precision is specified, then 0 is used by default.\n\nMariaDB also supports \'0000-00-00\' as a special zero-date value, unless\nNO_ZERO_DATE is specified in the SQL_MODE. Similarly, individual components of\na date can be set to 0 (for example: \'2015-00-12\'), unless NO_ZERO_IN_DATE is\nspecified in the SQL_MODE. In many cases, the result of en expression\ninvolving a zero-date, or a date with zero-parts, is NULL. If the\nALLOW_INVALID_DATES SQL_MODE is enabled, if the day part is in the range\nbetween 1 and 31, the date does not produce any error, even for months that\nhave less than 31 days.\n\nOracle Mode\n-----------\n\nMariaDB starting with 10.3\n--------------------------\nIn Oracle mode from MariaDB 10.3, DATE with a time portion is a synonym for\nDATETIME. See also mariadb_schema.\n\nInternal Format\n---------------\n\nIn MariaDB 10.1.2 a new temporal format was introduced from MySQL 5.6 that\nalters how the TIME, DATETIME and TIMESTAMP columns operate at lower levels.\nThese changes allow these temporal data types to have fractional parts and\nnegative values. You can disable this feature using the\nmysql56_temporal_format system variable.\n\nTables that include TIMESTAMP values that were created on an older version of\nMariaDB or that were created while the mysql56_temporal_format system variable\nwas disabled continue to store data using the older data type format.\n\nIn order to update table columns from the older format to the newer format,\nexecute an ALTER TABLE... MODIFY COLUMN statement that changes the column to\nthe *same* data type. This change may be needed if you want to export the\ntable\'s tablespace and import it onto a server that has\nmysql56_temporal_format=ON set (see MDEV-15225).\n\nFor instance, if you have a DATETIME column in your table:\n\nSHOW VARIABLES LIKE \'mysql56_temporal_format\';\n\n+-------------------------+-------+\n| Variable_name           | Value |\n+-------------------------+-------+\n| mysql56_temporal_format | ON    |\n+-------------------------+-------+\n\nALTER TABLE example_table MODIFY ts_col DATETIME;\n\nWhen MariaDB executes the ALTER TABLE statement, it converts the data from the\nolder temporal format to the newer one.\n\nIn the event that you have several tables and columns using temporal data\ntypes that you want to switch over to the new format, make sure the system\nvariable is enabled, then perform a dump and restore using mysqldump. The\ncolumns using relevant temporal data types are restored using the new temporal\nformat.\n\nStarting from MariaDB 10.5.1 columns with old temporal formats are marked with\na /* mariadb-5.3 */ comment in the output of SHOW CREATE TABLE, SHOW COLUMNS,\nDESCRIBE statements, as well as in the COLUMN_TYPE column of the\nINFORMATION_SCHEMA.COLUMNS Table.\n\nSHOW CREATE TABLE mariadb5312_datetime\\G\n*************************** 1. row ***************************\n   Table: mariadb5312_datetime\nCreate Table: CREATE TABLE `mariadb5312_datetime` (\n `dt0` datetime /* mariadb-5.3 */ DEFAULT NULL,\n `dt6` datetime(6) /* mariadb-5.3 */ DEFAULT NULL\n) ENGINE=MyISAM DEFAULT CHARSET=latin1\n\nExamples\n--------\n\nCREATE TABLE t1 (d DATETIME);\n\nINSERT INTO t1 VALUES (\"2011-03-11\"), (\"2012-04-19 13:08:22\"),\n (\"2013-07-18 13:44:22.123456\");\n\nSELECT * FROM t1;\n+---------------------+\n| d                   |\n+---------------------+\n| 2011-03-11 00:00:00 |\n| 2012-04-19 13:08:22 |\n| 2013-07-18 13:44:22 |\n+---------------------+\n\nCREATE TABLE t2 (d DATETIME(6));\n\nINSERT INTO t2 VALUES (\"2011-03-11\"), (\"2012-04-19 13:08:22\"),\n (\"2013-07-18 13:44:22.123456\");\n\nSELECT * FROM t2;\n+----------------------------+\n| d                          |\n+----------------------------+\n| 2011-03-11 00:00:00.000000 |\n| 2012-04-19 13:08:22.000000 |\n| 2013-07-18 13:44:22.123456 |\n+----------------------------++\n\nStrings used in datetime context are automatically converted to datetime(6).\nIf you want to have a datetime without seconds, you should use\nCONVERT(..,datetime).\n\nSELECT CONVERT(\'2007-11-30 10:30:19\',datetime);\n+-----------------------------------------+\n| CONVERT(\'2007-11-30 10:30:19\',datetime) |\n+-----------------------------------------+\n| 2007-11-30 10:30:19                     |\n+-----------------------------------------+\n\nSELECT CONVERT(\'2007-11-30 10:30:19\',datetime(6));\n+--------------------------------------------+\n| CONVERT(\'2007-11-30 10:30:19\',datetime(6)) |\n+--------------------------------------------+\n| 2007-11-30 10:30:19.000000                 |\n+--------------------------------------------+\n\nURL: https://mariadb.com/kb/en/datetime/','','https://mariadb.com/kb/en/datetime/'),
(762,'JSON_LOOSE',40,'Syntax\n------\n\nJSON_LOOSE(json_doc)\n\nDescription\n-----------\n\nAdds spaces to a JSON document to make it look more readable.\n\nExample\n-------\n\nSET @j = \'{ \"A\":1,\"B\":[2,3]}\';\n\nSELECT JSON_LOOSE(@j), @j;\n+-----------------------+--------------------+\n| JSON_LOOSE(@j)        | @j                 |\n+-----------------------+--------------------+\n| {\"A\": 1, \"B\": [2, 3]} | { \"A\":1,\"B\":[2,3]} |\n+-----------------------+--------------------+\n\nURL: https://mariadb.com/kb/en/json_loose/','','https://mariadb.com/kb/en/json_loose/'),
(763,'JSON_MERGE',40,'Syntax\n------\n\nJSON_MERGE(json_doc, json_doc[, json_doc] ...)\n\nDescription\n-----------\n\nMerges the given JSON documents.\n\nReturns the merged result,or NULL if any argument is NULL.\n\nAn error occurs if any of the arguments are not valid JSON documents.\n\nJSON_MERGE has been deprecated since MariaDB 10.2.25, MariaDB 10.3.16 and\nMariaDB 10.4.5. JSON_MERGE_PATCH is an RFC 7396-compliant replacement, and\nJSON_MERGE_PRESERVE is a synonym.\n\nExample\n-------\n\nSET @json1 = \'[1, 2]\';\nSET @json2 = \'[3, 4]\';\n\nSELECT JSON_MERGE(@json1,@json2);\n+---------------------------+\n| JSON_MERGE(@json1,@json2) |\n+---------------------------+\n| [1, 2, 3, 4]              |\n+---------------------------+\n\nURL: https://mariadb.com/kb/en/json_merge/','','https://mariadb.com/kb/en/json_merge/'),
(767,'JSON_OBJECT',40,'Syntax\n------\n\nJSON_OBJECT([key, value[, key, value] ...])\n\nDescription\n-----------\n\nReturns a JSON object containing the given key/value pairs. The key/value list\ncan be empty.\n\nAn error will occur if there are an odd number of arguments, or any key name\nis NULL.\n\nExample\n-------\n\nSELECT JSON_OBJECT(\"id\", 1, \"name\", \"Monty\");\n+---------------------------------------+\n| JSON_OBJECT(\"id\", 1, \"name\", \"Monty\") |\n+---------------------------------------+\n| {\"id\": 1, \"name\": \"Monty\"}            |\n+---------------------------------------+\n\nURL: https://mariadb.com/kb/en/json_object/','','https://mariadb.com/kb/en/json_object/'),
(296,'AUTO_INCREMENT',23,'Description\n-----------\n\nThe AUTO_INCREMENT attribute can be used to generate a unique identity for new\nrows. When you insert a new record to the table (or upon adding an\nAUTO_INCREMENT attribute with the ALTER TABLE statement), and the\nauto_increment field is NULL or DEFAULT (in the case of an INSERT), the value\nwill automatically be incremented. This also applies to 0, unless the\nNO_AUTO_VALUE_ON_ZERO SQL_MODE is enabled.\n\nAUTO_INCREMENT columns start from 1 by default. The automatically generated\nvalue can never be lower than 0.\n\nEach table can have only one AUTO_INCREMENT column. It must defined as a key\n(not necessarily the PRIMARY KEY or UNIQUE key). In some storage engines\n(including the default InnoDB), if the key consists of multiple columns, the\nAUTO_INCREMENT column must be the first column. Storage engines that permit\nthe column to be placed elsewhere are Aria, MyISAM, MERGE, Spider, TokuDB,\nBLACKHOLE, FederatedX and Federated.\n\nCREATE TABLE animals (\n  id MEDIUMINT NOT NULL AUTO_INCREMENT,\n  name CHAR(30) NOT NULL,\n  PRIMARY KEY (id)\n );\n\nINSERT INTO animals (name) VALUES\n  (\'dog\'),(\'cat\'),(\'penguin\'),\n  (\'fox\'),(\'whale\'),(\'ostrich\');\n\nSELECT * FROM animals;\n+----+---------+\n| id | name    |\n+----+---------+\n|  1 | dog     |\n|  2 | cat     |\n|  3 | penguin |\n|  4 | fox     |\n|  5 | whale   |\n|  6 | ostrich |\n+----+---------+\n\nSERIAL is an alias for BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE.\n\nCREATE TABLE t (id SERIAL, c CHAR(1)) ENGINE=InnoDB;\n\nSHOW CREATE TABLE t \\G\n*************************** 1. row ***************************\n   Table: t\nCreate Table: CREATE TABLE `t` (\n `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n `c` char(1) DEFAULT NULL,\n UNIQUE KEY `id` (`id`)\n) ENGINE=InnoDB DEFAULT CHARSET=latin1\n\nSetting or Changing the Auto_Increment Value\n--------------------------------------------\n\nYou can use an ALTER TABLE statement to assign a new value to the\nauto_increment table option, or set the insert_id server system variable to\nchange the next AUTO_INCREMENT value inserted by the current session.\n\nLAST_INSERT_ID() can be used to see the last AUTO_INCREMENT value inserted by\nthe current session.\n\nALTER TABLE animals AUTO_INCREMENT=8;\n\nINSERT INTO animals (name) VALUES (\'aardvark\');\n\nSELECT * FROM animals;\n+----+-----------+\n| id | name      |\n+----+-----------+\n|  1 | dog       |\n|  2 | cat       |\n|  3 | penguin   |\n|  4 | fox       |\n|  5 | whale     |\n|  6 | ostrich   |\n|  8 | aardvark  |\n+----+-----------+\n\nSET insert_id=12;\n\nINSERT INTO animals (name) VALUES (\'gorilla\');\n\nSELECT * FROM animals;\n+----+-----------+\n| id | name      |\n+----+-----------+\n|  1 | dog       |\n|  2 | cat       |\n|  3 | penguin   |\n|  4 | fox       |\n|  5 | whale     |\n|  6 | ostrich   |\n|  8 | aardvark  |\n| 12 | gorilla   |\n+----+-----------+\n\nInnoDB\n------\n\nUntil MariaDB 10.2.3, InnoDB used an auto-increment counter that is stored in\nmemory. When the server restarts, the counter is re-initialized to the highest\nvalue used in the table, which cancels the effects of any AUTO_INCREMENT = N\noption in the table statements.\n\nFrom MariaDB 10.2.4, this restriction has been lifted and AUTO_INCREMENT is\npersistent.\n\nSee also AUTO_INCREMENT Handling in InnoDB.\n\nSetting Explicit Values\n-----------------------\n\nIt is possible to specify a value for an AUTO_INCREMENT column. If the key is\nprimary or unique, the value must not already exist in the key.\n\nIf the new value is higher than the current maximum value, the AUTO_INCREMENT\nvalue is updated, so the next value will be higher. If the new value is lower\nthan the current maximum value, the AUTO_INCREMENT value remains unchanged.\n\nThe following example demonstrates these behaviors:\n\nCREATE TABLE t (id INTEGER UNSIGNED AUTO_INCREMENT PRIMARY KEY) ENGINE =\nInnoDB;\n\nINSERT INTO t VALUES (NULL);\nSELECT id FROM t;\n+----+\n| id |\n+----+\n|  1 |\n+----+\n\nINSERT INTO t VALUES (10); -- higher value\nSELECT id FROM t;\n+----+\n| id |\n+----+\n|  1 |\n| 10 |\n+----+\n\nINSERT INTO t VALUES (2); -- lower value\nINSERT INTO t VALUES (NULL); -- auto value\nSELECT id FROM t;\n+----+\n| id |\n+----+\n|  1 |\n|  2 |\n| 10 |\n| 11 |\n+----+\n\nThe ARCHIVE storage engine does not allow to insert a value that is lower than\nthe current maximum.\n\nMissing Values\n--------------\n\nAn AUTO_INCREMENT column normally has missing values. This happens because if\na row is deleted, or an AUTO_INCREMENT value is explicitly updated, old values\nare never re-used. The REPLACE statement also deletes a row, and its value is\nwasted. With InnoDB, values can be reserved by a transaction; but if the\ntransaction fails (for example, because of a ROLLBACK) the reserved value will\nbe lost.\n\nThus AUTO_INCREMENT values can be used to sort results in a chronological\norder, but not to create a numeric sequence.\n\nReplication\n-----------\n\nTo make master-master or Galera safe to use AUTO_INCREMENT one should use the\nsystem variables auto_increment_increment and auto_increment_offset to\ngenerate unique values for each server.\n\nCHECK Constraints, DEFAULT Values and Virtual Columns\n-----------------------------------------------------\n\nMariaDB starting with 10.2.6\n----------------------------\nFrom MariaDB 10.2.6 auto_increment columns are no longer permitted in CHECK\nconstraints, DEFAULT value expressions and virtual columns. They were\npermitted in earlier versions, but did not work correctly. See MDEV-11117.\n\nGenerating Auto_Increment Values When Adding the Attribute\n----------------------------------------------------------\n\nCREATE OR REPLACE TABLE t1 (a INT);\nINSERT t1 VALUES (0),(0),(0);\nALTER TABLE t1 MODIFY a INT NOT NULL AUTO_INCREMENT PRIMARY KEY;\nSELECT * FROM t1;\n+---+\n| a |\n+---+\n| 1 |\n| 2 |\n| 3 |\n+---+\n\nCREATE OR REPLACE TABLE t1 (a INT);\nINSERT t1 VALUES (5),(0),(8),(0);\nALTER TABLE t1 MODIFY a INT NOT NULL AUTO_INCREMENT PRIMARY KEY;\nSELECT * FROM t1;\n+---+\n| a |\n+---+\n| 5 |\n| 6 |\n| 8 |\n| 9 |\n+---+\n\nIf the NO_AUTO_VALUE_ON_ZERO SQL_MODE is set, zero values will not be\nautomatically incremented:\n\nSET SQL_MODE=\'no_auto_value_on_zero\';\nCREATE OR REPLACE TABLE t1 (a INT);\nINSERT t1 VALUES (3), (0);\nALTER TABLE t1 MODIFY a INT NOT NULL AUTO_INCREMENT PRIMARY KEY;\nSELECT * FROM t1;\n+---+\n| a |\n+---+\n| 0 |\n| 3 |\n+---+\n\nURL: https://mariadb.com/kb/en/auto_increment/','','https://mariadb.com/kb/en/auto_increment/'),
(769,'JSON_PRETTY',40,'JSON_PRETTY was added as an alias for JSON_DETAILED in MariaDB 10.10.3,\nMariaDB 10.9.5, MariaDB 10.8.7, MariaDB 10.7.8, MariaDB 10.6.12, MariaDB\n10.5.19 and MariaDB 10.4.28.\n\nURL: https://mariadb.com/kb/en/json_pretty/','','https://mariadb.com/kb/en/json_pretty/'),
(776,'JSON_SET',40,'Syntax\n------\n\nJSON_SET(json_doc, path, val[, path, val] ...)\n\nDescription\n-----------\n\nUpdates or inserts data into a JSON document, returning the result, or NULL if\nany of the arguments are NULL or the optional path fails to find an object.\n\nAn error will occur if the JSON document is invalid, the path is invalid or if\nthe path contains a * or wildcard.\n\nJSON_SET can update or insert data, while JSON_REPLACE can only update, and\nJSON_INSERT only insert.\n\nExamples\n--------\n\nSELECT JSON_SET(Priv, \'$.locked\', \'true\') FROM mysql.global_priv\n\nURL: https://mariadb.com/kb/en/json_set/','','https://mariadb.com/kb/en/json_set/'),
(782,'Window Functions Overview',41,'Introduction\n------------\n\nWindow functions allow calculations to be performed across a set of rows\nrelated to the current row.\n\nSyntax\n------\n\nfunction (expression) OVER (\n [ PARTITION BY expression_list ]\n [ ORDER BY order_list [ frame_clause ] ] )\n\nfunction:\n A valid window function\n\nexpression_list:\n expression | column_name [, expr_list ]\n\norder_list:\n expression | column_name [ ASC | DESC ]\n [, ... ]\n\nframe_clause:\n {ROWS | RANGE} {frame_border | BETWEEN frame_border AND frame_border}\n\nframe_border:\n | UNBOUNDED PRECEDING\n | UNBOUNDED FOLLOWING\n | CURRENT ROW\n | expr PRECEDING\n | expr FOLLOWING\n\nDescription\n-----------\n\nIn some ways, window functions are similar to aggregate functions in that they\nperform calculations across a set of rows. However, unlike aggregate\nfunctions, the output is not grouped into a single row.\n\nNon-aggregate window functions include\n\n* CUME_DIST\n* DENSE_RANK\n* FIRST_VALUE\n* LAG\n* LAST_VALUE\n* LEAD\n* MEDIAN\n* NTH_VALUE\n* NTILE\n* PERCENT_RANK\n* PERCENTILE_CONT\n* PERCENTILE_DISC\n* RANK, ROW_NUMBER\n\nAggregate functions that can also be used as window functions include\n\n* AVG\n* BIT_AND\n* BIT_OR\n* BIT_XOR\n* COUNT\n* MAX\n* MIN\n* STD\n* STDDEV\n* STDDEV_POP\n* STDDEV_SAMP\n* SUM\n* VAR_POP\n* VAR_SAMP\n* VARIANCE\n\nWindow function queries are characterised by the OVER keyword, following which\nthe set of rows used for the calculation is specified. By default, the set of\nrows used for the calculation (the \"window) is the entire dataset, which can\nbe ordered with the ORDER BY clause. The PARTITION BY clause is used to reduce\nthe window to a particular group within the dataset.\n\nFor example, given the following data:\n\nCREATE TABLE student (name CHAR(10), test CHAR(10), score TINYINT);\n\nINSERT INTO student VALUES \n (\'Chun\', \'SQL\', 75), (\'Chun\', \'Tuning\', 73),\n (\'Esben\', \'SQL\', 43), (\'Esben\', \'Tuning\', 31),\n (\'Kaolin\', \'SQL\', 56), (\'Kaolin\', \'Tuning\', 88),\n (\'Tatiana\', \'SQL\', 87), (\'Tatiana\', \'Tuning\', 83);\n\nthe following two queries return the average partitioned by test and by name\nrespectively:\n\nSELECT name, test, score, AVG(score) OVER (PARTITION BY test) \n AS average_by_test FROM student;\n+---------+--------+-------+-----------------+\n| name    | test   | score | average_by_test |\n+---------+--------+-------+-----------------+\n| Chun    | SQL    |    75 |         65.2500 |\n| Chun    | Tuning |    73 |         68.7500 |\n| Esben   | SQL    |    43 |         65.2500 |\n| Esben   | Tuning |    31 |         68.7500 |\n| Kaolin  | SQL    |    56 |         65.2500 |\n| Kaolin  | Tuning |    88 |         68.7500 |\n| Tatiana | SQL    |    87 |         65.2500 |\n| Tatiana | Tuning |    83 |         68.7500 |\n+---------+--------+-------+-----------------+\n\nSELECT name, test, score, AVG(score) OVER (PARTITION BY name) \n AS average_by_name FROM student;\n+---------+--------+-------+-----------------+\n| name    | test   | score | average_by_name |\n+---------+--------+-------+-----------------+\n| Chun    | SQL    |    75 |         74.0000 |\n| Chun    | Tuning |    73 |         74.0000 |\n| Esben   | SQL    |    43 |         37.0000 |\n| Esben   | Tuning |    31 |         37.0000 |\n| Kaolin  | SQL    |    56 |         72.0000 |\n| Kaolin  | Tuning |    88 |         72.0000 |\n| Tatiana | SQL    |    87 |         85.0000 |\n| Tatiana | Tuning |    83 |         85.0000 |\n+---------+--------+-------+-----------------+\n\nIt is also possible to specify which rows to include for the window function\n(for example, the current row and all preceding rows). See Window Frames for\nmore details.\n\nScope\n-----\n\nWindow functions were introduced in SQL:2003, and their definition was\nexpanded in subsequent versions of the standard. The last expansion was in the\nlatest version of the standard, SQL:2011.\n\nMost database products support a subset of the standard, they implement some\nfunctions defined as late as in SQL:2011, and at the same time leave some\nparts of SQL:2008 unimplemented.\n\nMariaDB:\n\n* Supports ROWS and RANGE-type frames\nAll kinds of frame bounds are supported, including RANGE PRECEDING|FOLLOWING n\nframe bounds (unlike PostgreSQL or MS SQL Server)\nDoes not yet support DATE[TIME] datatype and arithmetic for RANGE-type frames\n(MDEV-9727)\n\n* Does not support GROUPS-type frames (it seems that no popular database\nsupports it, either)\n\n* Does not support frame exclusion (no other database seems to support it,\neither) (MDEV-9724)\n* Does not support explicit NULLS FIRST or NULLS LAST.\n* Does not support nested navigation in window functions (this is\nVALUE_OF(expr AT row_marker [, default_value) syntax)\n\n* The following window functions are supported:\n\"Streamable\" window functions: ROW_NUMBER, RANK, DENSE_RANK, \nWindow functions that can be streamed once the number of rows in partition is\nknown: PERCENT_RANK, CUME_DIST, NTILE\n\n* Aggregate functions that are currently supported as window functions are:\nCOUNT, SUM, AVG, BIT_OR, BIT_AND, BIT_XOR.\n* Aggregate functions with the DISTINCT specifier (e.g. COUNT( DISTINCT x))\nare not supported as window functions.\n\nLinks\n-----\n\n* MDEV-6115 is the main jira task for window functions development. Other\ntasks are are attached as sub-tasks\n* bb-10.2-mdev9543 is the feature tree for window functions. Development is\nongoing, and this tree has the newest changes.\n* Testcases are in mysql-test/t/win*.test\n\nExamples\n--------\n\nGiven the following sample data:\n\nCREATE TABLE users (\n email VARCHAR(30),\n first_name VARCHAR(30),\n last_name VARCHAR(30),\n account_type VARCHAR(30)\n);\n\nINSERT INTO users VALUES \n (\'admin@boss.org\', \'Admin\', \'Boss\', \'admin\'),\n (\'bob.carlsen@foo.bar\', \'Bob\', \'Carlsen\', \'regular\'),\n (\'eddie.stevens@data.org\', \'Eddie\', \'Stevens\', \'regular\'),\n (\'john.smith@xyz.org\', \'John\', \'Smith\', \'regular\'),\n (\'root@boss.org\', \'Root\', \'Chief\', \'admin\')\n\nFirst, let\'s order the records by email alphabetically, giving each an\nascending rnum value starting with 1. This will make use of the ROW_NUMBER\nwindow function:\n\nSELECT row_number() OVER (ORDER BY email) AS rnum,\n  email, first_name, last_name, account_type\nFROM users ORDER BY email;\n+------+------------------------+------------+-----------+--------------+\n| rnum | email                  | first_name | last_name | account_type |\n+------+------------------------+------------+-----------+--------------+\n|    1 | admin@boss.org         | Admin      | Boss      | admin        |\n|    2 | bob.carlsen@foo.bar    | Bob        | Carlsen   | regular      |\n|    3 | eddie.stevens@data.org | Eddie      | Stevens   | regular      |\n|    4 | john.smith@xyz.org     | John       | Smith     | regular      |\n|    5 | root@boss.org          | Root       | Chief     | admin        |\n+------+------------------------+------------+-----------+--------------\n\nWe can generate separate sequences based on account type, using the PARTITION\nBY clause:\n\nSELECT row_number() OVER (PARTITION BY account_type ORDER BY email) AS rnum, \n email, first_name, last_name, account_type\nFROM users ORDER BY account_type,email;\n+------+------------------------+------------+-----------+--------------+\n| rnum | email                  | first_name | last_name | account_type |\n+------+------------------------+------------+-----------+--------------+\n|    1 | admin@boss.org         | Admin      | Boss      | admin        |\n|    2 | root@boss.org          | Root       | Chief     | admin        |\n|    1 | bob.carlsen@foo.bar    | Bob        | Carlsen   | regular      |\n|    2 | eddie.stevens@data.org | Eddie      | Stevens   | regular      |\n|    3 | john.smith@xyz.org     | John       | Smith     | regular      |\n+------+------------------------+------------+-----------+--------------+\n\nGiven the following structure and data, we want to find the top 5 salaries\nfrom each department.\n\nCREATE TABLE employee_salaries (dept VARCHAR(20), name VARCHAR(20), salary\nINT(11));\n\nINSERT INTO employee_salaries VALUES\n(\'Engineering\', \'Dharma\', 3500),\n(\'Engineering\', \'Binh\', 3000),\n(\'Engineering\', \'Adalynn\', 2800),\n(\'Engineering\', \'Samuel\', 2500),\n(\'Engineering\', \'Cveta\', 2200),\n(\'Engineering\', \'Ebele\', 1800),\n(\'Sales\', \'Carbry\', 500),\n(\'Sales\', \'Clytemnestra\', 400),\n(\'Sales\', \'Juraj\', 300),\n(\'Sales\', \'Kalpana\', 300),\n(\'Sales\', \'Svantepolk\', 250),\n(\'Sales\', \'Angelo\', 200);\n\nWe could do this without using window functions, as follows:\n\nselect dept, name, salary\nfrom employee_salaries as t1\nwhere (select count(t2.salary)\n   from employee_salaries as t2\n   where t1.name != t2.name and\n      t1.dept = t2.dept and\n      t2.salary > t1.salary) < 5\norder by dept, salary desc;\n\n+-------------+--------------+--------+\n| dept        | name         | salary |\n+-------------+--------------+--------+\n| Engineering | Dharma       |   3500 |\n| Engineering | Binh         |   3000 |\n| Engineering | Adalynn      |   2800 |\n| Engineering | Samuel       |   2500 |\n| Engineering | Cveta        |   2200 |\n| Sales       | Carbry       |    500 |\n| Sales       | Clytemnestra |    400 |\n| Sales       | Juraj        |    300 |\n| Sales       | Kalpana      |    300 |\n| Sales       | Svantepolk   |    250 |\n+-------------+--------------+--------+\n\nThis has a number of disadvantages:\n\n* if there is no index, the query could take a long time if the\nemployee_salary_table is large\n* Adding and maintaining indexes adds overhead, and even with indexes on dept\nand salary, each subquery execution adds overhead by performing a lookup\nthrough the index.\n\nLet\'s try achieve the same with window functions. First, generate a rank for\nall employees, using the RANK function.\n\nselect rank() over (partition by dept order by salary desc) as ranking,\n  dept, name, salary\n  from employee_salaries\n  order by dept, ranking;\n+---------+-------------+--------------+--------+\n| ranking | dept        | name         | salary |\n+---------+-------------+--------------+--------+\n|       1 | Engineering | Dharma       |   3500 |\n|       2 | Engineering | Binh         |   3000 |\n|       3 | Engineering | Adalynn      |   2800 |\n|       4 | Engineering | Samuel       |   2500 |\n|       5 | Engineering | Cveta        |   2200 |\n|       6 | Engineering | Ebele        |   1800 |\n|       1 | Sales       | Carbry       |    500 |\n|       2 | Sales       | Clytemnestra |    400 |\n|       3 | Sales       | Juraj        |    300 |\n|       3 | Sales       | Kalpana      |    300 |\n|       5 | Sales       | Svantepolk   |    250 |\n|       6 | Sales       | Angelo       |    200 |\n+---------+-------------+--------------+--------+\n\nEach department has a separate sequence of ranks due to the PARTITION BY\nclause. This particular sequence of values for rank() is given by the ORDER BY\nclause inside the window function’s OVER clause. Finally, to get our results\nin a readable format we order the data by dept and the newly generated ranking\ncolumn.\n\nNow, we need to reduce the results to find only the top 5 per department. Here\nis a common mistake:\n\nselect\nrank() over (partition by dept order by salary desc) as ranking,\ndept, name, salary\nfrom employee_salaries\nwhere ranking <= 5\norder by dept, ranking;\n\nERROR 1054 (42S22): Unknown column \'ranking\' in \'where clause\'\n\nTrying to filter only the first 5 values per department by putting a where\nclause in the statement does not work, due to the way window functions are\ncomputed. The computation of window functions happens after all WHERE, GROUP\nBY and HAVING clauses have been completed, right before ORDER BY, so the WHERE\nclause has no idea that the ranking column exists. It is only present after we\nhave filtered and grouped all the rows.\n\nTo counteract this problem, we need to wrap our query into a derived table. We\ncan then attach a where clause to it:\n\nselect *from (select rank() over (partition by dept order by salary desc) as\nranking,\n dept, name, salary\nfrom employee_salaries) as salary_ranks\nwhere (salary_ranks.ranking <= 5)\n order by dept, ranking;\n+---------+-------------+--------------+--------+\n| ranking | dept        | name         | salary |\n+---------+-------------+--------------+--------+\n|       1 | Engineering | Dharma       |   3500 |\n|       2 | Engineering | Binh         |   3000 |\n|       3 | Engineering | Adalynn      |   2800 |\n|       4 | Engineering | Samuel       |   2500 |\n|       5 | Engineering | Cveta        |   2200 |\n|       1 | Sales       | Carbry       |    500 |\n|       2 | Sales       | Clytemnestra |    400 |\n|       3 | Sales       | Juraj        |    300 |\n|       3 | Sales       | Kalpana      |    300 |\n|       5 | Sales       | Svantepolk   |    250 |\n+---------+-------------+--------------+--------+\n\nURL: https://mariadb.com/kb/en/window-functions-overview/','','https://mariadb.com/kb/en/window-functions-overview/'),
(789,'NTH_VALUE',41,'Syntax\n------\n\nNTH_VALUE (expr[, num_row]) OVER ( \n [ PARTITION BY partition_expression ]\n [ ORDER BY order_list ]\n)\n\nDescription\n-----------\n\nThe NTH_VALUE function returns the value evaluated at row number num_row of\nthe window frame, starting from 1, or NULL if the row does not exist.\n\nURL: https://mariadb.com/kb/en/nth_value/','','https://mariadb.com/kb/en/nth_value/'),
(299,'CASE Statement',24,'Syntax\n------\n\nCASE case_value\n  WHEN when_value THEN statement_list\n  [WHEN when_value THEN statement_list] ...\n  [ELSE statement_list]\nEND CASE\n\nOr:\n\nCASE\n  WHEN search_condition THEN statement_list\n  [WHEN search_condition THEN statement_list] ...\n  [ELSE statement_list]\nEND CASE\n\nDescription\n-----------\n\nThe text on this page describes the CASE statement for stored programs. See\nthe CASE OPERATOR for details on the CASE operator outside of stored programs.\n\nThe CASE statement for stored programs implements a complex conditional\nconstruct. If a search_condition evaluates to true, the corresponding SQL\nstatement list is executed. If no search condition matches, the statement list\nin the ELSE clause is executed. Each statement_list consists of one or more\nstatements.\n\nThe CASE statement cannot have an ELSE NULL clause, and it is terminated with\nEND CASE instead of END. implements a complex conditional construct. If a\nsearch_condition evaluates to true, the corresponding SQL statement list is\nexecuted. If no search condition matches, the statement list in the ELSE\nclause is executed. Each statement_list consists of one or more statements.\n\nIf no when_value or search_condition matches the value tested and the CASE\nstatement contains no ELSE clause, a Case not found for CASE statement error\nresults.\n\nEach statement_list consists of one or more statements; an empty\nstatement_list is not allowed. To handle situations where no value is matched\nby any WHEN clause, use an ELSE containing an empty BEGIN ... END block, as\nshown in this example:\n\nDELIMITER |\nCREATE PROCEDURE p()\nBEGIN\n DECLARE v INT DEFAULT 1;\n CASE v\n  WHEN 2 THEN SELECT v;\n  WHEN 3 THEN SELECT 0;\n  ELSE BEGIN END;\n END CASE;\nEND;\n|\n\nThe indentation used here in the ELSE clause is for purposes of clarity only,\nand is not otherwise significant. See Delimiters in the mariadb client for\nmore on the use of the delimiter command.\n\nNote: The syntax of the CASE statement used inside stored programs differs\nslightly from that of the SQL CASE expression described in CASE OPERATOR. The\nCASE statement cannot have an ELSE NULL clause, and it is terminated with END\nCASE instead of END.\n\nURL: https://mariadb.com/kb/en/case-statement/','','https://mariadb.com/kb/en/case-statement/'),
(300,'DECLARE CONDITION',24,'Syntax\n------\n\nDECLARE condition_name CONDITION FOR condition_value\n\ncondition_value:\n  SQLSTATE [VALUE] sqlstate_value\n | mysql_error_code\n\nDescription\n-----------\n\nThe DECLARE ... CONDITION statement defines a named error condition. It\nspecifies a condition that needs specific handling and associates a name with\nthat condition. Later, the name can be used in a DECLARE ... HANDLER, SIGNAL\nor RESIGNAL statement (as long as the statement is located in the same BEGIN\n... END block).\n\nConditions must be declared after local variables, but before CURSORs and\nHANDLERs.\n\nA condition_value for DECLARE ... CONDITION can be an SQLSTATE value (a\n5-character string literal) or a MySQL error code (a number). You should not\nuse SQLSTATE value \'00000\' or MySQL error code 0, because those indicate\nsucess rather than an error condition. If you try, or if you specify an\ninvalid SQLSTATE value, an error like this is produced:\n\nERROR 1407 (42000): Bad SQLSTATE: \'00000\'\n\nFor a list of SQLSTATE values and MariaDB error codes, see MariaDB Error Codes.\n\nURL: https://mariadb.com/kb/en/declare-condition/','','https://mariadb.com/kb/en/declare-condition/'),
(302,'DECLARE Variable',24,'Syntax\n------\n\nDECLARE var_name [, var_name] ... [[ROW] TYPE OF]] type [DEFAULT value]\n\nDescription\n-----------\n\nThis statement is used to declare local variables within stored programs. To\nprovide a default value for the variable, include a DEFAULT clause. The value\ncan be specified as an expression (even subqueries are permitted); it need not\nbe a constant. If the DEFAULT clause is missing, the initial value is NULL.\n\nLocal variables are treated like stored routine parameters with respect to\ndata type and overflow checking. See CREATE PROCEDURE.\n\nLocal variables must be declared before CONDITIONs, CURSORs and HANDLERs.\n\nLocal variable names are not case sensitive.\n\nThe scope of a local variable is within the BEGIN ... END block where it is\ndeclared. The variable can be referred to in blocks nested within the\ndeclaring block, except those blocks that declare a variable with the same\nname.\n\nTYPE OF / ROW TYPE OF\n---------------------\n\nMariaDB starting with 10.3\n--------------------------\nTYPE OF and ROW TYPE OF anchored data types for stored routines were\nintroduced in MariaDB 10.3.\n\nAnchored data types allow a data type to be defined based on another object,\nsuch as a table row, rather than specifically set in the declaration. If the\nanchor object changes, so will the anchored data type. This can lead to\nroutines being easier to maintain, so that if the data type in the table is\nchanged, it will automatically be changed in the routine as well.\n\nVariables declared with ROW TYPE OF will have the same features as implicit\nROW variables. It is not possible to use ROW TYPE OF variables in a LIMIT\nclause.\n\nThe real data type of TYPE OF and ROW TYPE OF table_name will become known at\nthe very beginning of the stored routine call. ALTER TABLE or DROP TABLE\nstatements performed inside the current routine on the tables that appear in\nanchors won\'t affect the data type of the anchored variables, even if the\nvariable is declared after an ALTER TABLE or DROP TABLE statement.\n\nThe real data type of a ROW TYPE OF cursor_name variable will become known\nwhen execution enters into the block where the variable is declared. Data type\ninstantiation will happen only once. In a cursor ROW TYPE OF variable that is\ndeclared inside a loop, its data type will become known on the very first\niteration and won\'t change on further loop iterations.\n\nThe tables referenced in TYPE OF and ROW TYPE OF declarations will be checked\nfor existence at the beginning of the stored routine call. CREATE PROCEDURE or\nCREATE FUNCTION will not check the referenced tables for existence.\n\nExamples\n--------\n\nTYPE OF and ROW TYPE OF from MariaDB 10.3:\n\nDECLARE tmp TYPE OF t1.a; -- Get the data type from the column {{a}} in the\ntable {{t1}}\n\nDECLARE rec1 ROW TYPE OF t1; -- Get the row data type from the table {{t1}}\n\nDECLARE rec2 ROW TYPE OF cur1; -- Get the row data type from the cursor\n{{cur1}}\n\nURL: https://mariadb.com/kb/en/declare-variable/','','https://mariadb.com/kb/en/declare-variable/'),
(796,'Aggregate Functions as Window Functions',41,'It is possible to use aggregate functions as window functions. An aggregate\nfunction used as a window function must have the OVER clause. For example,\nhere\'s COUNT() used as a window function:\n\nselect COUNT(*) over  (order by column) from table;\n\nMariaDB currently allows these aggregate functions to be used as window\nfunctions:\n\n* AVG\n* BIT_AND\n* BIT_OR\n* BIT_XOR\n* COUNT\n* JSON_ARRAYAGG\n* JSON_OBJECTAGG\n* MAX\n* MIN\n* STD\n* STDDEV\n* STDDEV_POP\n* STDDEV_SAMP\n* SUM\n* VAR_POP\n* VAR_SAMP\n* VARIANCE\n\nURL: https://mariadb.com/kb/en/aggregate-functions-as-window-functions/','','https://mariadb.com/kb/en/aggregate-functions-as-window-functions/');
INSERT INTO `help_topic` VALUES
(797,'ColumnStore Window Functions',41,'Introduction\n------------\n\nMariaDB ColumnStore provides support for window functions broadly following\nthe SQL 2003 specification. A window function allows for calculations relating\nto a window of data surrounding the current row in a result set. This\ncapability provides for simplified queries in support of common business\nquestions such as cumulative totals, rolling averages, and top 10 lists.\n\nAggregate functions are utilized for window functions however differ in\nbehavior from a group by query because the rows remain ungrouped. This\nprovides support for cumulative sums and rolling averages, for example.\n\nTwo key concepts for window functions are Partition and Frame:\n\n* A Partition is a group of rows, or window, that have the same value for a\nspecific column, for example a Partition can be created over a time period\nsuch as a quarter or lookup values.\n* The Frame for each row  is a subset of the row\'s Partition. The frame\ntypically is dynamic allowing for a sliding frame of rows within the\nPartition. The Frame determines the range of rows for the windowing function.\nA Frame could be defined as the last X rows and next Y rows all the way up to\nthe entire Partition.\n\nWindow functions are applied after joins, group by, and having clauses are\ncalculated.\n\nSyntax\n------\n\nA window function is applied in the select clause using the following syntax:\n\nfunction_name ([expression [, expression ... ]]) OVER ( window_definition )\n\nwhere window_definition is defined as:\n\n[ PARTITION BY expression [, ...] ]\n[ ORDER BY expression [ ASC | DESC ] [ NULLS { FIRST | LAST } ] [, ...] ]\n[ frame_clause ]\n\nPARTITION BY:\n\n* Divides the window result set into groups based on one or more expressions.\n* An expression may be a constant, column, and non window function expressions.\n* A query is not limited to a single partition by clause. Different partition\nclauses can be used across different window function applications.\n* The partition by columns do not need to be in the select list but do need to\nbe available from the query result set.\n* If there is no PARTITION BY clause, all rows of the result set define the\ngroup.\n\nORDER BY\n\n* Defines the ordering of values within the partition.\n* Can be ordered by multiple keys which may be a constant, column or non\nwindow function expression.\n* The order by columns do not need to be in the select list but need to be\navailable from the query result set.\n* Use of a select column alias from the query is not supported.\n* ASC (default) and DESC options allow for ordering ascending or descending.\n* NULLS FIRST and NULL_LAST options specify whether null values come first or\nlast in the ordering sequence. NULLS_FIRST is the default for ASC order, and\nNULLS_LAST is the default for DESC order.\n\nand the optional frame_clause is defined as:\n\n{ RANGE | ROWS } frame_start\n{ RANGE | ROWS } BETWEEN frame_start AND frame_end\n\nand the optional frame_start and frame_end are defined as (value being a\nnumeric expression):\n\nUNBOUNDED PRECEDING\nvalue PRECEDING\nCURRENT ROW\nvalue FOLLOWING\nUNBOUNDED FOLLOWING\n\nRANGE/ROWS:\n\n* Defines the windowing clause for calculating the set of rows that the\nfunction applies to for calculating a given rows window function result.\n* Requires an ORDER BY clause to define the row order for the window.\n* ROWS specify the window in physical units, i.e. result set rows and must be\na constant or expression evaluating to a positive numeric value.\n* RANGE specifies the window as a logical offset. If the the expression\nevaluates to a numeric value then the ORDER BY expression must be a numeric or\nDATE type. If the expression evaluates to an interval value then the ORDER BY\nexpression must be a DATE data type.\n* UNBOUNDED PRECEDING indicates the window starts at the first row of the\npartition.\n* UNBOUNDED FOLLOWING indicates the window ends at the last row of the\npartition.\n* CURRENT ROW specifies the window start or ends at the current row or value.\n* If omitted, the default is ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW.\n\nSupported Functions\n-------------------\n\n+--------------------------------+-------------------------------------------+\n| Function                       | Description                               |\n+--------------------------------+-------------------------------------------+\n| AVG()                          | The average of all input values.          |\n+--------------------------------+-------------------------------------------+\n| COUNT()                        | Number of input rows.                     |\n+--------------------------------+-------------------------------------------+\n| CUME_DIST()                    | Calculates the cumulative distribution,   |\n|                                | or relative rank, of the current row to   |\n|                                | other rows in the same partition. Number  |\n|                                | of peer or preceding rows / number of     |\n|                                | rows in partition.                        |\n+--------------------------------+-------------------------------------------+\n| DENSE_RANK()                   | Ranks items in a group leaving no gaps    |\n|                                | in ranking sequence when there are ties.  |\n+--------------------------------+-------------------------------------------+\n| FIRST_VALUE()                  | The value evaluated at the row that is    |\n|                                | the first row of the window frame         |\n|                                | (counting from 1); null if no such row.   |\n+--------------------------------+-------------------------------------------+\n| LAG()                          | The value evaluated at the row that is    |\n|                                | offset rows before the current row        |\n|                                | within the partition; if there is no      |\n|                                | such row, instead return default. Both    |\n|                                | offset and default are evaluated with     |\n|                                | respect to the current row. If omitted,   |\n|                                | offset defaults to 1 and default to       |\n|                                | null. LAG provides access to more than    |\n|                                | one row of a table at the same time       |\n|                                | without a self-join. Given a series of    |\n|                                | rows returned from a query and a          |\n|                                | position of the cursor, LAG provides      |\n|                                | access to a row at a given physical       |\n|                                | offset prior to that position.            |\n+--------------------------------+-------------------------------------------+\n| LAST_VALUE()                   | The value evaluated at the row that is    |\n|                                | the last row of the window frame          |\n|                                | (counting from 1); null if no such row.   |\n+--------------------------------+-------------------------------------------+\n| LEAD()                         | Provides access to a row at a given       |\n|                                | physical offset beyond that position.     |\n|                                | Returns value evaluated at the row that   |\n|                                | is offset rows after the current row      |\n|                                | within the partition; if there is no      |\n|                                | such row, instead return default. Both    |\n|                                | offset and default are evaluated with     |\n|                                | respect to the current row. If omitted,   |\n|                                | offset defaults to 1 and default to null. |\n+--------------------------------+-------------------------------------------+\n| MAX()                          | Maximum value of expression across all    |\n|                                | input values.                             |\n+--------------------------------+-------------------------------------------+\n| MEDIAN()                       | An inverse distribution function that     |\n|                                | assumes a continuous distribution model.  |\n|                                | It takes a numeric or datetime value and  |\n|                                | returns the middle value or an            |\n|                                | interpolated value that would be the      |\n|                                | middle value once the values are sorted.  |\n|                                | Nulls are ignored in the calculation.     |\n+--------------------------------+-------------------------------------------+\n| MIN()                          | Minimum value of expression across all    |\n|                                | input values.                             |\n+--------------------------------+-------------------------------------------+\n| NTH_VALUE()                    | The value evaluated at the row that is    |\n|                                | the nth row of the window frame           |\n|                                | (counting from 1); null if no such row.   |\n+--------------------------------+-------------------------------------------+\n| NTILE()                        | Divides an ordered data set into a        |\n|                                | number of buckets indicated by expr and   |\n|                                | assigns the appropriate bucket number to  |\n|                                | each row. The buckets are numbered 1      |\n|                                | through expr. The expr value must         |\n|                                | resolve to a positive constant for each   |\n|                                | partition. Integer ranging from 1 to the  |\n|                                | argument value, dividing the partition    |\n|                                | as equally as possible.                   |\n+--------------------------------+-------------------------------------------+\n| PERCENT_RANK()                 | relative rank of the current row: (rank   |\n|                                | - 1) / (total rows - 1).                  |\n+--------------------------------+-------------------------------------------+\n| PERCENTILE_CONT()              | An inverse distribution function that     |\n|                                | assumes a continuous distribution model.  |\n|                                | It takes a percentile value and a sort    |\n|                                | specification, and returns an             |\n|                                | interpolated value that would fall into   |\n|                                | that percentile value with respect to     |\n|                                | the sort specification. Nulls are         |\n|                                | ignored in the calculation.               |\n+--------------------------------+-------------------------------------------+\n| PERCENTILE_DISC()              | An inverse distribution function that     |\n|                                | assumes a discrete distribution model.    |\n|                                | It takes a percentile value and a sort    |\n|                                | specification and returns an element      |\n|                                | from the set. Nulls are ignored in the    |\n|                                | calculation.                              |\n+--------------------------------+-------------------------------------------+\n| RANK()                         | rank of the current row with gaps; same   |\n|                                | as row_number of its first peer.          |\n+--------------------------------+-------------------------------------------+\n| ROW_NUMBER()                   | number of the current row within its      |\n|                                | partition, counting from 1                |\n+--------------------------------+-------------------------------------------+\n| STDDEV() STDDEV_POP()          | Computes the population standard          |\n|                                | deviation and returns the square root of  |\n|                                | the population variance.                  |\n+--------------------------------+-------------------------------------------+\n| STDDEV_SAMP()                  | Computes the cumulative sample standard   |\n|                                | deviation and returns the square root of  |\n|                                | the sample variance.                      |\n+--------------------------------+-------------------------------------------+\n| SUM()                          | Sum of expression across all input        |\n|                                | values.                                   |\n+--------------------------------+-------------------------------------------+\n| VARIANCE() VAR_POP()           | Population variance of the input values   |\n|                                | (square of the population standard        |\n|                                | deviation).                               |\n+--------------------------------+-------------------------------------------+\n| VAR_SAMP()                     | Sample variance of the input values       |\n|                                | (square of the sample standard            |\n|                                | deviation).                               |\n+--------------------------------+-------------------------------------------+\n\nExamples\n--------\n\nExample Schema\n--------------\n\nThe examples are all based on the following simplified sales opportunity table:\n\ncreate table opportunities (\nid int,\naccountName varchar(20),\nname varchar(128),\nowner varchar(7),\namount decimal(10,2),\ncloseDate date,\nstageName varchar(11)\n) engine=columnstore;\n\nSome example values are (thanks to https://www.mockaroo.com for sample data\ngeneration):\n\n+----+---------------+------+--------+---------+-------------+-------------+\n| id | accountName   | name | owner  | amount  | closeDate   | stageName   |\n+----+---------------+------+--------+---------+-------------+-------------+\n| 1  | Browseblab    | Mult | Bob    | 26444.8 | 2016-10-20  | Negotiating |\n|    |               | -lat |        |         |             |             |\n|    |               | ral  |        |         |             |             |\n|    |               | exec |        |         |             |             |\n|    |               | tive |        |         |             |             |\n|    |               | func |        |         |             |             |\n|    |               | ion  |        |         |             |             |\n+----+---------------+------+--------+---------+-------------+-------------+\n| 2  | Mita          | Orga | Maria  | 477878. | 2016-11-28  | ClosedWon   |\n|    |               | ic   |        | 1       |             |             |\n|    |               | dema |        |         |             |             |\n|    |               | d-dr |        |         |             |             |\n|    |               | ven  |        |         |             |             |\n|    |               | benc |        |         |             |             |\n|    |               | mark |        |         |             |             |\n+----+---------------+------+--------+---------+-------------+-------------+\n| 3  | Miboo         | De-e | Olivie | 80181.7 | 2017-01-05  | ClosedWon   |\n|    |               | gine |        |         |             |             |\n|    |               | red  |        |         |             |             |\n|    |               | hybr |        |         |             |             |\n|    |               | d    |        |         |             |             |\n|    |               | grou |        |         |             |             |\n|    |               | ware |        |         |             |             |\n+----+---------------+------+--------+---------+-------------+-------------+\n| 4  | Youbridge     | Ente | Chris  | 946245. | 2016-07-02  | ClosedWon   |\n|    |               | pris |        | 9       |             |             |\n|    |               | -wid |        |         |             |             |\n|    |               |      |        |         |             |             |\n|    |               | bott |        |         |             |             |\n|    |               | m-li |        |         |             |             |\n|    |               | e    |        |         |             |             |\n|    |               | Grap |        |         |             |             |\n|    |               | ic   |        |         |             |             |\n|    |               | Inte |        |         |             |             |\n|    |               | face |        |         |             |             |\n+----+---------------+------+--------+---------+-------------+-------------+\n| 5  | Skyba         | Reve | Maria  | 696241. | 2017-02-17  | Negotiating |\n|    |               | se-e |        | 2       |             |             |\n|    |               | gine |        |         |             |             |\n|    |               | red  |        |         |             |             |\n|    |               | fres |        |         |             |             |\n|    |               | -thi |        |         |             |             |\n|    |               | king |        |         |             |             |\n|    |               | stan |        |         |             |             |\n|    |               | ardi |        |         |             |             |\n|    |               | atio |        |         |             |             |\n|    |               |      |        |         |             |             |\n+----+---------------+------+--------+---------+-------------+-------------+\n| 6  | Eayo          | Fund | Bob    | 765605. | 2016-08-27  | Prospecting |\n|    |               | ment |        | 2       |             |             |\n|    |               | l    |        |         |             |             |\n|    |               | well |        |         |             |             |\n|    |               | modu |        |         |             |             |\n|    |               | ated |        |         |             |             |\n|    |               | arti |        |         |             |             |\n|    |               | icia |        |         |             |             |\n|    |               |      |        |         |             |             |\n|    |               | inte |        |         |             |             |\n|    |               | lige |        |         |             |             |\n|    |               | ce   |        |         |             |             |\n+----+---------------+------+--------+---------+-------------+-------------+\n| 7  | Yotz          | Exte | Chris  | 319624. | 2017-01-06  | ClosedLost  |\n|    |               | ded  |        | 0       |             |             |\n|    |               | seco |        |         |             |             |\n|    |               | dary |        |         |             |             |\n|    |               | infr |        |         |             |             |\n|    |               | stru |        |         |             |             |\n|    |               | ture |        |         |             |             |\n+----+---------------+------+--------+---------+-------------+-------------+\n| 8  | Oloo          | Conf | Chris  | 321016. | 2017-03-08  | ClosedLost  |\n|    |               | gura |        | 6       |             |             |\n|    |               | le   |        |         |             |             |\n|    |               | web- |        |         |             |             |\n|    |               | nabl |        |         |             |             |\n|    |               | d    |        |         |             |             |\n|    |               | data |        |         |             |             |\n|    |               | ware |        |         |             |             |\n|    |               | ouse |        |         |             |             |\n+----+---------------+------+--------+---------+-------------+-------------+\n| 9  | Kaymbo        | Mult | Bob    | 690881. | 2017-01-02  | Developing  |\n|    |               | -lat |        | 1       |             |             |\n|    |               | ral  |        |         |             |             |\n|    |               | web- |        |         |             |             |\n|    |               | nabl |        |         |             |             |\n|    |               | d    |        |         |             |             |\n|    |               | defi |        |         |             |             |\n|    |               | itio |        |         |             |             |\n|    |               |      |        |         |             |             |\n+----+---------------+------+--------+---------+-------------+-------------+\n| 10 | Rhyloo        | Publ | Chris  | 965477. | 2016-11-07  | Prospecting |\n|    |               | c-ke |        | 4       |             |             |\n|    |               |      |        |         |             |             |\n|    |               | cohe |        |         |             |             |\n|    |               | ent  |        |         |             |             |\n|    |               | infr |        |         |             |             |\n|    |               | stru |        |         |             |             |\n|    |               | ture |        |         |             |             |\n+----+---------------+------+--------+---------+-------------+-------------+\n\nThe schema, sample data, and queries are available as an attachment to this\narticle.\n\nCumulative Sum and Running Max Example\n--------------------------------------\n\nWindow functions can be used to achieve cumulative / running calculations on a\ndetail report. In this case a won opportunity report for a 7 day period adds\ncolumns to show the accumulated won amount as well as the current highest\nopportunity amount in preceding rows.\n\nselect owner, \naccountName, \nCloseDate, \namount, \nsum(amount) over (order by CloseDate rows between unbounded preceding and\ncurrent row) cumeWon, \nmax(amount) over (order by CloseDate rows between unbounded preceding and\ncurrent row) runningMax\nfrom opportunities \nwhere stageName=\'ClosedWon\' \nand closeDate >= \'2016-10-02\' and closeDate <= \'2016-10-09\' \norder by CloseDate;\n\nwith example results:\n\n+--------+---------------+-------------+---------+----------+--------------+\n| owner  | accountName   | CloseDate   | amount  | cumeWon  | runningMax   |\n+--------+---------------+-------------+---------+----------+--------------+\n| Bill   | Babbleopia    | 2016-10-02  | 437636. | 437636.4 | 437636.47    |\n|        |               |             | 7       |          |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Bill   | Thoughtworks  | 2016-10-04  | 146086. | 583722.9 | 437636.47    |\n|        |               |             | 1       |          |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Olivie | Devpulse      | 2016-10-05  | 834235. | 1417958. | 834235.93    |\n|        |               |             | 3       | 1        |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Chris  | Linkbridge    | 2016-10-07  | 539977. | 2458738. | 834235.93    |\n|        |               |             | 5       | 5        |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Olivie | Trupe         | 2016-10-07  | 500802. | 1918761. | 834235.93    |\n|        |               |             | 9       | 0        |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Bill   | Latz          | 2016-10-08  | 857254. | 3315993. | 857254.87    |\n|        |               |             | 7       | 2        |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Chris  | Avamm         | 2016-10-09  | 699566. | 4015560. | 857254.87    |\n|        |               |             | 6       | 8        |              |\n+--------+---------------+-------------+---------+----------+--------------+\n\nPartitioned Cumulative Sum and Running Max Example\n--------------------------------------------------\n\nThe above example can be partitioned, so that the window functions are over a\nparticular field grouping such as owner and accumulate within that grouping.\nThis is achieved by adding the syntax \"partition by <columns>\" in the window\nfunction clause.\n\nselect owner,  \naccountName,  \nCloseDate,  \namount,  \nsum(amount) over (partition by owner order by CloseDate rows between unbounded\npreceding and current row) cumeWon,  \nmax(amount) over (partition by owner order by CloseDate rows between unbounded\npreceding and current row) runningMax \nfrom opportunities  \nwhere stageName=\'ClosedWon\' \nand closeDate >= \'2016-10-02\' and closeDate <= \'2016-10-09\'  \norder by owner, CloseDate;\n\nwith example results:\n\n+--------+---------------+-------------+---------+----------+--------------+\n| owner  | accountName   | CloseDate   | amount  | cumeWon  | runningMax   |\n+--------+---------------+-------------+---------+----------+--------------+\n| Bill   | Babbleopia    | 2016-10-02  | 437636. | 437636.4 | 437636.47    |\n|        |               |             | 7       |          |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Bill   | Thoughtworks  | 2016-10-04  | 146086. | 583722.9 | 437636.47    |\n|        |               |             | 1       |          |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Bill   | Latz          | 2016-10-08  | 857254. | 1440977. | 857254.87    |\n|        |               |             | 7       | 5        |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Chris  | Linkbridge    | 2016-10-07  | 539977. | 539977.4 | 539977.45    |\n|        |               |             | 5       |          |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Chris  | Avamm         | 2016-10-09  | 699566. | 1239544. | 699566.86    |\n|        |               |             | 6       | 1        |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Olivie | Devpulse      | 2016-10-05  | 834235. | 834235.9 | 834235.93    |\n|        |               |             | 3       |          |              |\n+--------+---------------+-------------+---------+----------+--------------+\n| Olivie | Trupe         | 2016-10-07  | 500802. | 1335038. | 834235.93    |\n|        |               |             | 9       | 2        |              |\n+--------+---------------+-------------+---------+----------+--------------+\n\nRanking / Top Results\n---------------------\n\nThe rank window function allows for ranking or assigning a numeric order value\nbased on the window function definition. Using the Rank() function will result\nin the same value for ties / equal values and the next rank value skipped. The\nDense_Rank() function behaves similarly except the next consecutive number is\nused after a tie rather than skipped. The Row_Number() function will provide a\nunique ordering value. The example query shows the Rank() function being\napplied to rank sales reps by the number of opportunities for Q4 2016.\n\nselect owner, \nwonCount, \nrank() over (order by wonCount desc) rank \nfrom (\n select owner,\n count(*) wonCount\n from opportunities\n where stageName=\'ClosedWon\'\n and closeDate >= \'2016-10-01\' and closeDate < \'2016-12-31\'\n group by owner\n) t\norder by rank;\n\nwith example results (note the query is technically incorrect by using\ncloseDate < \'2016-12-31\' however this creates a tie scenario for illustrative\npurposes):\n\n+----------------------+----------------------------------+------------------+\n| owner                | wonCount                         | rank             |\n+----------------------+----------------------------------+------------------+\n| Bill                 | 19                               | 1                |\n+----------------------+----------------------------------+------------------+\n| Chris                | 15                               | 2                |\n+----------------------+----------------------------------+------------------+\n| Maria                | 14                               | 3                |\n+----------------------+----------------------------------+------------------+\n| Bob                  | 14                               | 3                |\n+----------------------+----------------------------------+------------------+\n| Olivier              | 10                               | 5                |\n+----------------------+----------------------------------+------------------+\n\nIf the dense_rank function is used the rank values would be 1,2,3,3,4 and for\nthe row_number function the values would be 1,2,3,4,5.\n\nFirst and Last Values\n---------------------\n\nThe first_value and last_value functions allow determining the first and last\nvalues of a given range. Combined with a group by this allows summarizing\nopening and closing values. The example shows a more complex case where\ndetailed information is presented for first and last opportunity by quarter.\n\nselect a.year, \na.quarter, \nf.accountName firstAccountName, \nf.owner firstOwner, \nf.amount firstAmount, \nl.accountName lastAccountName, \nl.owner lastOwner, \nl.amount lastAmount \nfrom (\n select year,\n quarter,\n min(firstId) firstId,\n min(lastId) lastId\n from (\n  select year(closeDate) year,\n  quarter(closeDate) quarter,\n  first_value(id) over (partition by year(closeDate), quarter(closeDate)\norder by closeDate rows between unbounded preceding and current row) firstId, \n  last_value(id) over (partition by year(closeDate), quarter(closeDate)\norder by closeDate rows between current row and unbounded following) lastId \n  from opportunities  where stageName=\'ClosedWon\'\n ) t\n group by year, quarter order by year,quarter\n) a \njoin opportunities f on a.firstId = f.id \njoin opportunities l on a.lastId = l.id \norder by year, quarter;\n\nwith example results:\n\n+----+------+------------+--------+---------+-----------+-------+--------+\n| ye | quar | firstAccou | firstO | firstAm | lastAccou | lastO | lastAm |\n| r  | er   | tName      | ner    | unt     | tName     | ner   | unt    |\n+----+------+------------+--------+---------+-----------+-------+--------+\n| 20 | 3    | Skidoo     | Bill   | 523295. | Skipstorm | Bill  | 151420 |\n| 6  |      |            |        | 7       |           |       | 86     |\n+----+------+------------+--------+---------+-----------+-------+--------+\n| 20 | 4    | Skimia     | Chris  | 961513. | Avamm     | Maria | 112493 |\n| 6  |      |            |        | 9       |           |       | 65     |\n+----+------+------------+--------+---------+-----------+-------+--------+\n| 20 | 1    | Yombu      | Bob    | 536875. | Skaboo    | Chris | 270273 |\n| 7  |      |            |        | 1       |           |       | 08     |\n+----+------+------------+--------+---------+-----------+-------+--------+\n\nPrior and Next Example\n----------------------\n\nSometimes it useful to understand the previous and next values in the context\nof a given row. The lag and lead window functions provide this capability. By\ndefault the offset is one providing the prior or next value but can also be\nprovided to get a larger offset. The example query is a report of\nopportunities by account name showing the opportunity amount, and the prior\nand next opportunity amount for that account by close date.\n\nselect accountName, \ncloseDate,  \namount currentOppAmount, \nlag(amount) over (partition by accountName order by closeDate) priorAmount,\nlead(amount) over (partition by accountName order by closeDate) nextAmount \nfrom opportunities \norder by accountName, closeDate \nlimit 9;\n\nwith example results:\n\n+--------------+-----------+-------------------+--------------+-------------+\n| accountName  | closeDate | currentOppAmount  | priorAmount  | nextAmount  |\n+--------------+-----------+-------------------+--------------+-------------+\n| Abata        | 2016-09-1 | 645098.45         | NULL         | 161086.82   |\n|              |           |                   |              |             |\n+--------------+-----------+-------------------+--------------+-------------+\n| Abata        | 2016-10-1 | 161086.82         | 645098.45    | 350235.75   |\n|              |           |                   |              |             |\n+--------------+-----------+-------------------+--------------+-------------+\n| Abata        | 2016-12-1 | 350235.75         | 161086.82    | 878595.89   |\n|              |           |                   |              |             |\n+--------------+-----------+-------------------+--------------+-------------+\n| Abata        | 2016-12-3 | 878595.89         | 350235.75    | 922322.39   |\n|              |           |                   |              |             |\n+--------------+-----------+-------------------+--------------+-------------+\n| Abata        | 2017-01-2 | 922322.39         | 878595.89    | NULL        |\n|              |           |                   |              |             |\n+--------------+-----------+-------------------+--------------+-------------+\n| Abatz        | 2016-10-1 | 795424.15         | NULL         | NULL        |\n|              |           |                   |              |             |\n+--------------+-----------+-------------------+--------------+-------------+\n| Agimba       | 2016-07-0 | 288974.84         | NULL         | 914461.49   |\n|              |           |                   |              |             |\n+--------------+-----------+-------------------+--------------+-------------+\n| Agimba       | 2016-09-0 | 914461.49         | 288974.84    | 176645.52   |\n|              |           |                   |              |             |\n+--------------+-----------+-------------------+--------------+-------------+\n| Agimba       | 2016-09-2 | 176645.52         | 914461.49    | NULL        |\n|              |           |                   |              |             |\n+--------------+-----------+-------------------+--------------+-------------+\n\nQuartiles Example\n-----------------\n\nThe NTile window function allows for breaking up a data set into portions\nassigned a numeric value to each portion of the range. NTile(4) breaks the\ndata up into quartiles (4 sets). The example query produces a report of all\nopportunities summarizing the quartile boundaries of amount values.\n\nselect t.quartile, \nmin(t.amount) min, \nmax(t.amount) max \nfrom (\n select amount,\n ntile(4) over (order by amount asc) quartile\n from opportunities\n where closeDate >= \'2016-10-01\' and closeDate <= \'2016-12-31\'\n ) t\ngroup by quartile \norder by quartile;\n\nWith example results:\n\n+-----------------------------------------+----------------+----------------+\n| quartile                                | min            | max            |\n+-----------------------------------------+----------------+----------------+\n| 1                                       | 6337.15        | 287634.01      |\n+-----------------------------------------+----------------+----------------+\n| 2                                       | 288796.14      | 539977.45      |\n+-----------------------------------------+----------------+----------------+\n| 3                                       | 540070.04      | 748727.51      |\n+-----------------------------------------+----------------+----------------+\n| 4                                       | 753670.77      | 998864.47      |\n+-----------------------------------------+----------------+----------------+\n\nPercentile Example\n------------------\n\nThe percentile functions have a slightly different syntax from other window\nfunctions as can be seen in the example below. These functions can be only\napplied against numeric values. The argument to the function is the percentile\nto evaluate. Following \'within group\' is the sort expression which indicates\nthe sort column and optionally order. Finally after \'over\' is an optional\npartition by clause, for no partition clause use \'over ()\'. The example below\nutilizes the value 0.5 to calculate the median opportunity amount in the rows.\nThe values differ sometimes because percentile_cont will return the average of\nthe 2 middle rows for an even data set while percentile_desc returns the first\nencountered in the sort.\n\nselect owner,  \naccountName,  \nCloseDate,  \namount,\npercentile_cont(0.5) within group (order by amount) over (partition by owner)\npct_cont,\npercentile_disc(0.5) within group (order by amount) over (partition by owner)\npct_disc\nfrom opportunities  \nwhere stageName=\'ClosedWon\' \nand closeDate >= \'2016-10-02\' and closeDate <= \'2016-10-09\'  \norder by owner, CloseDate;\n\nWith example results:\n\n+--------+----------------+-------------+---------+------------+------------+\n| owner  | accountName    | CloseDate   | amount  | pct_cont   | pct_disc   |\n+--------+----------------+-------------+---------+------------+------------+\n| Bill   | Babbleopia     | 2016-10-02  | 437636. | 437636.470 | 437636.47  |\n|        |                |             | 7       | 000000     |            |\n+--------+----------------+-------------+---------+------------+------------+\n| Bill   | Thoughtworks   | 2016-10-04  | 146086. | 437636.470 | 437636.47  |\n|        |                |             | 1       | 000000     |            |\n+--------+----------------+-------------+---------+------------+------------+\n| Bill   | Latz           | 2016-10-08  | 857254. | 437636.470 | 437636.47  |\n|        |                |             | 7       | 000000     |            |\n+--------+----------------+-------------+---------+------------+------------+\n| Chris  | Linkbridge     | 2016-10-07  | 539977. | 619772.155 | 539977.45  |\n|        |                |             | 5       | 000000     |            |\n+--------+----------------+-------------+---------+------------+------------+\n| Chris  | Avamm          | 2016-10-09  | 699566. | 619772.155 | 539977.45  |\n|        |                |             | 6       | 000000     |            |\n+--------+----------------+-------------+---------+------------+------------+\n| Olivie | Devpulse       | 2016-10-05  | 834235. | 667519.110 | 500802.29  |\n|        |                |             | 3       | 000000     |            |\n+--------+----------------+-------------+---------+------------+------------+\n| Olivie | Trupe          | 2016-10-07  | 500802. | 667519.110 | 500802.29  |\n|        |                |             | 9       | 000000     |            |\n+--------+----------------+-------------+---------+------------+------------+\n\nURL: https://mariadb.com/kb/en/window-functions-columnstore-window-functions/','','https://mariadb.com/kb/en/window-functions-columnstore-window-functions/'),
(802,'SPIDER_FLUSH_TABLE_MON_CACHE',42,'Syntax\n------\n\nSPIDER_FLUSH_TABLE_MON_CACHE()\n\nDescription\n-----------\n\nA UDF installed with the Spider Storage Engine, this function is used for\nrefreshing monitoring server information. It returns a value of 1.\n\nExamples\n--------\n\nSELECT SPIDER_FLUSH_TABLE_MON_CACHE();\n+--------------------------------+\n| SPIDER_FLUSH_TABLE_MON_CACHE() |\n+--------------------------------+\n|                              1 |\n+--------------------------------+\n\nURL: https://mariadb.com/kb/en/spider_flush_table_mon_cache/','','https://mariadb.com/kb/en/spider_flush_table_mon_cache/'),
(301,'DECLARE HANDLER',24,'Syntax\n------\n\nDECLARE handler_type HANDLER\n  FOR condition_value [, condition_value] ...\n  statement\n\nhandler_type:\n  CONTINUE\n | EXIT\n | UNDO\n\ncondition_value:\n  SQLSTATE [VALUE] sqlstate_value\n | condition_name\n | SQLWARNING\n | NOT FOUND\n | SQLEXCEPTION\n | mariadb_error_code\n\nDescription\n-----------\n\nThe DECLARE ... HANDLER statement specifies handlers that each may deal with\none or more conditions. If one of these conditions occurs, the specified\nstatement is executed. statement can be a simple statement (for example, SET\nvar_name = value), or it can be a compound statement written using BEGIN and\nEND.\n\nHandlers must be declared after local variables, a CONDITION and a CURSOR.\n\nFor a CONTINUE handler, execution of the current program continues after\nexecution of the handler statement. For an EXIT handler, execution terminates\nfor the BEGIN ... END compound statement in which the handler is declared.\n(This is true even if the condition occurs in an inner block.) The UNDO\nhandler type statement is not supported.\n\nIf a condition occurs for which no handler has been declared, the default\naction is EXIT.\n\nA condition_value for DECLARE ... HANDLER can be any of the following values:\n\n* An SQLSTATE value (a 5-character string literal) or a MariaDB error\ncode (a number). You should not use SQLSTATE value \'00000\' or MariaDB\nerror code 0, because those indicate sucess rather than an error\ncondition. For a list of SQLSTATE values and MariaDB error codes, see\nMariaDB Error Codes.\n* A condition name previously specified with DECLARE ... CONDITION. It must be\nin the same stored program. See DECLARE CONDITION.\n* SQLWARNING is shorthand for the class of SQLSTATE values that begin\nwith \'01\'.\n* NOT FOUND is shorthand for the class of SQLSTATE values that begin\nwith \'02\'. This is relevant only the context of cursors and is used to\ncontrol what happens when a cursor reaches the end of a data set. If\nno more rows are available, a No Data condition occurs with SQLSTATE\nvalue 02000. To detect this condition, you can set up a handler for it\n(or for a NOT FOUND condition). An example is shown in Cursor Overview. This\ncondition also occurs for SELECT ... INTO var_list statements that retrieve no\nrows.\n* SQLEXCEPTION is shorthand for the class of SQLSTATE values that do\nnot begin with \'00\', \'01\', or \'02\'.\n\nWhen an error raises, in some cases it could be handled by multiple HANDLERs.\nFor example, there may be an handler for 1050 error, a separate handler for\nthe 42S01 SQLSTATE, and another separate handler for the SQLEXCEPTION class:\nin theory all occurrences of HANDLER may catch the 1050 error, but MariaDB\nchooses the HANDLER with the highest precedence. Here are the precedence rules:\n\n* Handlers which refer to an error code have the highest precedence.\n* Handlers which refer to a SQLSTATE come next.\n* Handlers which refer to an error class have the lowest precedence.\n\nIn some cases, a statement could produce multiple errors. If this happens, in\nsome cases multiple handlers could have the highest precedence. In such cases,\nthe choice of the handler is indeterminate.\n\nNote that if an error occurs within a CONTINUE HANDLER block, it can be\nhandled by another HANDLER. However, a HANDLER which is already in the stack\n(that is, it has been called to handle an error and its execution didn\'t\nfinish yet) cannot handle new errors—this prevents endless loops. For example,\nsuppose that a stored procedure contains a CONTINUE HANDLER for SQLWARNING and\nanother CONTINUE HANDLER for NOT FOUND. At some point, a NOT FOUND error\noccurs, and the execution enters the NOT FOUND HANDLER. But within that\nhandler, a warning occurs, and the execution enters the SQLWARNING HANDLER. If\nanother NOT FOUND error occurs, it cannot be handled again by the NOT FOUND\nHANDLER, because its execution is not finished.\n\nWhen a DECLARE HANDLER block can handle more than one error condition, it may\nbe useful to know which errors occurred. To do so, you can use the GET\nDIAGNOSTICS statement.\n\nAn error that is handled by a DECLARE HANDLER construct can be issued again\nusing the RESIGNAL statement.\n\nBelow is an example using DECLARE HANDLER:\n\nCREATE TABLE test.t (s1 INT, PRIMARY KEY (s1));\n\nDELIMITER //\n\nCREATE PROCEDURE handlerdemo ( )\n  BEGIN\n   DECLARE CONTINUE HANDLER FOR SQLSTATE \'23000\' SET @x2 = 1;\n   SET @x = 1;\n   INSERT INTO test.t VALUES (1);\n   SET @x = 2;\n   INSERT INTO test.t VALUES (1);\n   SET @x = 3;\n  END;\n  //\n\nDELIMITER ;\n\nCALL handlerdemo( );\n\nSELECT @x;\n+------+\n| @x   |\n+------+\n|    3 |\n+------+\n\nURL: https://mariadb.com/kb/en/declare-handler/','','https://mariadb.com/kb/en/declare-handler/'),
(303,'FOR',24,'MariaDB starting with 10.3\n--------------------------\nFOR loops were introduced in MariaDB 10.3.\n\nSyntax\n------\n\nInteger range FOR loop:\n\n[begin_label:]\nFOR var_name IN [ REVERSE ] lower_bound .. upper_bound\nDO statement_list\nEND FOR [ end_label ]\n\nExplicit cursor FOR loop\n\n[begin_label:]\nFOR record_name IN cursor_name [ ( cursor_actual_parameter_list)]\nDO statement_list\nEND FOR [ end_label ]\n\nExplicit cursor FOR loop (Oracle mode)\n\n[begin_label:]\nFOR record_name IN cursor_name [ ( cursor_actual_parameter_list)]\nLOOP\n statement_list\nEND LOOP [ end_label ]\n\nImplicit cursor FOR loop\n\n[begin_label:]\nFOR record_name IN ( select_statement )\nDO statement_list\nEND FOR [ end_label ]\n\nDescription\n-----------\n\nFOR loops allow code to be executed a fixed number of times.\n\nIn an integer range FOR loop, MariaDB will compare the lower bound and upper\nbound values, and assign the lower bound value to a counter. If REVERSE is not\nspecified, and the upper bound value is greater than or equal to the counter,\nthe counter will be incremented and the statement will continue, after which\nthe loop is entered again. If the upper bound value is greater than the\ncounter, the loop will be exited.\n\nIf REVERSE is specified, the counter is decremented, and the upper bound value\nneeds to be less than or equal for the loop to continue.\n\nExamples\n--------\n\nIntger range FOR loop:\n\nCREATE TABLE t1 (a INT);\n\nDELIMITER //\n\nFOR i IN 1..3\nDO\n INSERT INTO t1 VALUES (i);\nEND FOR;\n//\n\nDELIMITER ;\n\nSELECT * FROM t1;\n+------+\n| a    |\n+------+\n|    1 |\n|    2 |\n|    3 |\n+------+\n\nREVERSE integer range FOR loop:\n\nCREATE OR REPLACE TABLE t1 (a INT);\n\nDELIMITER //\nFOR i IN REVERSE 4..12\n  DO\n  INSERT INTO t1 VALUES (i);\nEND FOR;\n//\nQuery OK, 9 rows affected (0.422 sec)\n\nDELIMITER ;\n\nSELECT * FROM t1;\n+------+\n| a    |\n+------+\n|   12 |\n|   11 |\n|   10 |\n|    9 |\n|    8 |\n|    7 |\n|    6 |\n|    5 |\n|    4 |\n+------+\n\nExplicit cursor in Oracle mode:\n\nSET sql_mode=ORACLE;\n\nCREATE OR REPLACE TABLE t1 (a INT, b VARCHAR(32));\n\nINSERT INTO t1 VALUES (10,\'b0\');\nINSERT INTO t1 VALUES (11,\'b1\');\nINSERT INTO t1 VALUES (12,\'b2\');\n\nDELIMITER //\n\nCREATE OR REPLACE PROCEDURE p1(pa INT) AS \n CURSOR cur(va INT) IS\n  SELECT a, b FROM t1 WHERE a=va;\nBEGIN\n FOR rec IN cur(pa)\n LOOP\n  SELECT rec.a, rec.b;\n END LOOP;\nEND;\n//\n\nDELIMITER ;\n\nCALL p1(10);\n+-------+-------+\n| rec.a | rec.b |\n+-------+-------+\n|    10 | b0    |\n+-------+-------+\n\nCALL p1(11);\n+-------+-------+\n| rec.a | rec.b |\n+-------+-------+\n|    11 | b1    |\n+-------+-------+\n\nCALL p1(12);\n+-------+-------+\n| rec.a | rec.b |\n+-------+-------+\n|    12 | b2    |\n+-------+-------+\n\nCALL p1(13);\nQuery OK, 0 rows affected (0.000 sec)\n\nURL: https://mariadb.com/kb/en/for/','','https://mariadb.com/kb/en/for/'),
(306,'ITERATE',24,'Syntax\n------\n\nITERATE label\n\nITERATE can appear only within LOOP, REPEAT, and WHILE statements. ITERATE\nmeans \"do the loop again\", and uses the statement\'s label to determine which\nstatements to repeat. The label must be in the same stored program, not in a\ncaller procedure.\n\nIf you try to use ITERATE with a non-existing label, or if the label is\nassociated to a construct which is not a loop, the following error will be\nproduced:\n\nERROR 1308 (42000): ITERATE with no matching label: <label_name>\n\nBelow is an example of how ITERATE might be used:\n\nCREATE PROCEDURE doiterate(p1 INT)\nBEGIN\n label1: LOOP\n  SET p1 = p1 + 1;\n  IF p1 < 10 THEN ITERATE label1; END IF;\n  LEAVE label1;\n END LOOP label1;\n SET @x = p1;\nEND\n\nURL: https://mariadb.com/kb/en/iterate/','','https://mariadb.com/kb/en/iterate/'),
(307,'Labels',24,'Syntax\n------\n\nlabel: <construct>\n[label]\n\nLabels are MariaDB identifiers which can be used to identify a BEGIN ... END\nconstruct or a loop. They have a maximum length of 16 characters and can be\nquoted with backticks (i.e.., `).\n\nLabels have a start part and an end part. The start part must precede the\nportion of code it refers to, must be followed by a colon (:) and can be on\nthe same or different line. The end part is optional and adds nothing, but can\nmake the code more readable. If used, the end part must precede the\nconstruct\'s delimiter (;). Constructs identified by a label can be nested.\nEach construct can be identified by only one label.\n\nLabels need not be unique in the stored program they belong to. However, a\nlabel for an inner loop cannot be identical to a label for an outer loop. In\nthis case, the following error would be produced:\n\nERROR 1309 (42000): Redefining label <label_name>\n\nLEAVE and ITERATE statements can be used to exit or repeat a portion of code\nidentified by a label. They must be in the same Stored Routine, Trigger or\nEvent which contains the target label.\n\nBelow is an example using a simple label that is used to exit a LOOP:\n\nCREATE PROCEDURE `test_sp`()\nBEGIN\n `my_label`:\n LOOP\n   SELECT \'looping\';\n   LEAVE `my_label`;\n END LOOP;\n SELECT \'out of loop\';\nEND;\n\nThe following label is used to exit a procedure, and has an end part:\n\nCREATE PROCEDURE `test_sp`()\n`my_label`:\nBEGIN\n IF @var = 1 THEN\n   LEAVE `my_label`;\n END IF;\n DO something();\nEND `my_label`;\n\nURL: https://mariadb.com/kb/en/labels/','','https://mariadb.com/kb/en/labels/'),
(308,'LEAVE',24,'Syntax\n------\n\nLEAVE label\n\nThis statement is used to exit the flow control construct that has the given\nlabel. The label must be in the same stored program, not in a caller\nprocedure. LEAVE can be used within BEGIN ... END or loop constructs (LOOP,\nREPEAT, WHILE). In Stored Procedures, Triggers and Events, LEAVE can refer to\nthe outmost BEGIN ... END construct; in that case, the program exits the\nprocedure. In Stored Functions, RETURN can be used instead.\n\nNote that LEAVE cannot be used to exit a DECLARE HANDLER block.\n\nIf you try to LEAVE a non-existing label, or if you try to LEAVE a HANDLER\nblock, the following error will be produced:\n\nERROR 1308 (42000): LEAVE with no matching label: <label_name>\n\nThe following example uses LEAVE to exit the procedure if a condition is true:\n\nCREATE PROCEDURE proc(IN p TINYINT)\nCONTAINS SQL\n`whole_proc`:\nBEGIN\n SELECT 1;\n IF p < 1 THEN\n   LEAVE `whole_proc`;\n END IF;\n SELECT 2;\nEND;\n\nCALL proc(0);\n+---+\n| 1 |\n+---+\n| 1 |\n+---+\n\nURL: https://mariadb.com/kb/en/leave/','','https://mariadb.com/kb/en/leave/'),
(310,'REPEAT LOOP',24,'Syntax\n------\n\n[begin_label:] REPEAT\n  statement_list\nUNTIL search_condition\nEND REPEAT [end_label]\n\nThe statement list within a REPEAT statement is repeated until the\nsearch_condition is true. Thus, a REPEAT always enters the loop at least once.\nstatement_list consists of one or more statements, each terminated by a\nsemicolon (i.e., ;) statement delimiter.\n\nA REPEAT statement can be labeled. end_label cannot be given unless\nbegin_label also is present. If both are present, they must be the same.\n\nSee Delimiters in the mariadb client for more on client delimiter usage.\n\nDELIMITER //\n\nCREATE PROCEDURE dorepeat(p1 INT)\n BEGIN\n  SET @x = 0;\n  REPEAT SET @x = @x + 1; UNTIL @x > p1 END REPEAT;\n END\n//\n\nCALL dorepeat(1000)//\n\nSELECT @x//\n+------+\n| @x   |\n+------+\n| 1001 |\n+------+\n\nURL: https://mariadb.com/kb/en/repeat-loop/','','https://mariadb.com/kb/en/repeat-loop/'),
(313,'SELECT INTO',24,'Syntax\n------\n\nSELECT col_name [, col_name] ...\n  INTO var_name [, var_name] ...\n  table_expr\n\nDescription\n-----------\n\nSELECT ... INTO enables selected columns to be stored directly into variables.\nNo resultset is produced. The query should return a single row. If the query\nreturns no rows, a warning with error code 1329 occurs (No data), and the\nvariable values remain unchanged. If the query returns multiple rows, error\n1172 occurs (Result consisted of more than one row). If it is possible that\nthe statement may retrieve multiple rows, you can use LIMIT 1 to limit the\nresult set to a single row.\n\nThe INTO clause can also be specified at the end of the statement.\n\nIn the context of such statements that occur as part of events executed by the\nEvent Scheduler, diagnostics messages (not only errors, but also warnings) are\nwritten to the error log, and, on Windows, to the application event log.\n\nThis statement can be used with both local variables and user-defined\nvariables.\n\nFor the complete syntax, see SELECT.\n\nAnother way to set a variable\'s value is the SET statement.\n\nSELECT ... INTO results are not stored in the query cache even if SQL_CACHE is\nspecified.\n\nExamples\n--------\n\nSELECT id, data INTO @x,@y \nFROM test.t1 LIMIT 1;\nSELECT * from t1 where t1.a=@x and t1.b=@y\n\nIf you want to use this construct with UNION you have to use the syntax:\n\nSELECT  * INTO @x FROM (SELECT t1.a FROM t1 UNION SELECT t2.a FROM t2);\n\nURL: https://mariadb.com/kb/en/selectinto/','','https://mariadb.com/kb/en/selectinto/'),
(804,'COLUMN_CHECK',43,'Syntax\n------\n\nCOLUMN_CHECK(dyncol_blob);\n\nDescription\n-----------\n\nCheck if dyncol_blob is a valid packed dynamic columns blob. Return value of 1\nmeans the blob is valid, return value of 0 means it is not.\n\nRationale: Normally, one works with valid dynamic column blobs. Functions like\nCOLUMN_CREATE, COLUMN_ADD, COLUMN_DELETE always return valid dynamic column\nblobs. However, if a dynamic column blob is accidentally truncated, or\ntranscoded from one character set to another, it will be corrupted. This\nfunction can be used to check if a value in a blob field is a valid dynamic\ncolumn blob.\n\nURL: https://mariadb.com/kb/en/column_check/','','https://mariadb.com/kb/en/column_check/'),
(806,'COLUMN_DELETE',43,'Syntax\n------\n\nCOLUMN_DELETE(dyncol_blob, column_nr, column_nr...);\nCOLUMN_DELETE(dyncol_blob, column_name, column_name...);\n\nDescription\n-----------\n\nDeletes a dynamic column with the specified name. Multiple names can be given.\nThe return value is a dynamic column blob after the modification.\n\nURL: https://mariadb.com/kb/en/column_delete/','','https://mariadb.com/kb/en/column_delete/'),
(807,'COLUMN_EXISTS',43,'Syntax\n------\n\nCOLUMN_EXISTS(dyncol_blob, column_nr);\nCOLUMN_EXISTS(dyncol_blob, column_name);\n\nDescription\n-----------\n\nChecks if a column with name column_name exists in dyncol_blob. If yes, return\n1, otherwise return 0. See dynamic columns for more information.\n\nURL: https://mariadb.com/kb/en/column_exists/','','https://mariadb.com/kb/en/column_exists/'),
(311,'RESIGNAL',24,'Syntax\n------\n\nRESIGNAL [error_condition]\n  [SET error_property\n  [, error_property] ...]\n\nerror_condition:\n  SQLSTATE [VALUE] \'sqlstate_value\'\n | condition_name\n\nerror_property:\n  error_property_name = <error_property_value>\n\nerror_property_name:\n  CLASS_ORIGIN\n | SUBCLASS_ORIGIN\n | MESSAGE_TEXT\n | MYSQL_ERRNO\n | CONSTRAINT_CATALOG\n | CONSTRAINT_SCHEMA\n | CONSTRAINT_NAME\n | CATALOG_NAME\n | SCHEMA_NAME\n | TABLE_NAME\n | COLUMN_NAME\n | CURSOR_NAME\n\nDescription\n-----------\n\nThe syntax of RESIGNAL and its semantics are very similar to SIGNAL. This\nstatement can only be used within an error HANDLER. It produces an error, like\nSIGNAL. RESIGNAL clauses are the same as SIGNAL, except that they all are\noptional, even SQLSTATE. All the properties which are not specified in\nRESIGNAL, will be identical to the properties of the error that was received\nby the error HANDLER. For a description of the clauses, see diagnostics area.\n\nNote that RESIGNAL does not empty the diagnostics area: it just appends\nanother error condition.\n\nRESIGNAL, without any clauses, produces an error which is identical to the\nerror that was received by HANDLER.\n\nIf used out of a HANDLER construct, RESIGNAL produces the following error:\n\nERROR 1645 (0K000): RESIGNAL when handler not active\n\nIn MariaDB 5.5, if a HANDLER contained a CALL to another procedure, that\nprocedure could use RESIGNAL. Since MariaDB 10.0, trying to do this raises the\nabove error.\n\nFor a list of SQLSTATE values and MariaDB error codes, see MariaDB Error Codes.\n\nThe following procedure tries to query two tables which don\'t exist, producing\na 1146 error in both cases. Those errors will trigger the HANDLER. The first\ntime the error will be ignored and the client will not receive it, but the\nsecond time, the error is re-signaled, so the client will receive it.\n\nCREATE PROCEDURE test_error( )\nBEGIN\n DECLARE CONTINUE HANDLER\n   FOR 1146\n BEGIN\n IF @hide_errors IS FALSE THEN\n   RESIGNAL;\n END IF;\n END;\n SET @hide_errors = TRUE;\n SELECT \'Next error will be ignored\' AS msg;\n SELECT `c` FROM `temptab_one`;\n SELECT \'Next error won\'\'t be ignored\' AS msg;\n SET @hide_errors = FALSE;\n SELECT `c` FROM `temptab_two`;\nEND;\n\nCALL test_error( );\n\n+----------------------------+\n| msg                        |\n+----------------------------+\n| Next error will be ignored |\n+----------------------------+\n\n+-----------------------------+\n| msg                         |\n+-----------------------------+\n| Next error won\'t be ignored |\n+-----------------------------+\n\nERROR 1146 (42S02): Table \'test.temptab_two\' doesn\'t exist\n\nThe following procedure re-signals an error, modifying only the error message\nto clarify the cause of the problem.\n\nCREATE PROCEDURE test_error()\nBEGIN\n DECLARE CONTINUE HANDLER\n FOR 1146\n BEGIN\n   RESIGNAL SET\n   MESSAGE_TEXT = \'`temptab` does not exist\';\n END;\n SELECT `c` FROM `temptab`;\nEND;\n\nCALL test_error( );\nERROR 1146 (42S02): `temptab` does not exist\n\nAs explained above, this works on MariaDB 5.5, but produces a 1645 error since\n10.0.\n\nCREATE PROCEDURE handle_error()\nBEGIN\n RESIGNAL;\nEND;\nCREATE PROCEDURE p()\nBEGIN\n DECLARE EXIT HANDLER FOR SQLEXCEPTION CALL p();\n SIGNAL SQLSTATE \'45000\';\nEND;\n\nURL: https://mariadb.com/kb/en/resignal/','','https://mariadb.com/kb/en/resignal/'),
(317,'DECLARE CURSOR',24,'Syntax\n------\n\n<= MariaDB 10.2\n\nDECLARE cursor_name CURSOR FOR select_statement\n\nFrom MariaDB 10.3\n\nDECLARE cursor_name CURSOR [(cursor_formal_parameter[,...])] FOR\nselect_statement\n\ncursor_formal_parameter:\n  name type [collate clause]\n\nFrom MariaDB 10.8\n\nDECLARE cursor_name CURSOR [(cursor_formal_parameter[,...])] FOR\nselect_statement\n\ncursor_formal_parameter:\n  [IN] name type [collate clause]\n\nDescription\n-----------\n\nThis statement declares a cursor. Multiple cursors may be declared in a stored\nprogram, but each cursor in a given block must have a unique name.\n\nselect_statement is not executed until the OPEN statement is executed. It is\nimportant to remember this if the query produces an error, or calls functions\nwhich have side effects.\n\nA SELECT associated to a cursor can use variables, but the query itself cannot\nbe a variable, and cannot be dynamically composed. The SELECT statement cannot\nhave an INTO clause.\n\nCursors must be declared before HANDLERs, but after local variables and\nCONDITIONs.\n\nParameters\n----------\n\nMariaDB starting with 10.3.0\n----------------------------\nFrom MariaDB 10.3.0, cursors can have parameters. This is a non-standard SQL\nextension. Cursor parameters can appear in any part of the DECLARE CURSOR\nselect_statement where a stored procedure variable is allowed (select list,\nWHERE, HAVING, LIMIT etc).\n\nIN\n--\n\nMariaDB starting with 10.8.0\n----------------------------\nFrom MariaDB 10.8.0 preview release, the IN qualifier is supported in the\ncursor_format_parameter part of the syntax.\n\nSee Cursor Overview for an example.\n\nURL: https://mariadb.com/kb/en/declare-cursor/','','https://mariadb.com/kb/en/declare-cursor/'),
(810,'COLUMN_LIST',43,'Syntax\n------\n\nCOLUMN_LIST(dyncol_blob);\n\nDescription\n-----------\n\nReturns a comma-separated list of column names. The names are quoted with\nbackticks.\n\nSee dynamic columns for more information.\n\nURL: https://mariadb.com/kb/en/column_list/','','https://mariadb.com/kb/en/column_list/'),
(811,'WSREP_LAST_SEEN_GTID',44,'MariaDB starting with 10.4.2\n----------------------------\nWSREP_LAST_SEEN_GTID was added as part of Galera 4 in MariaDB 10.4.2.\n\nSyntax\n------\n\nWSREP_LAST_SEEN_GTID()\n\nDescription\n-----------\n\nReturns the Global Transaction ID of the most recent write transaction\nobserved by the client.\n\nThe result can be useful to determine the transaction to provide to\nWSREP_SYNC_WAIT_UPTO_GTID for waiting and unblocking purposes.\n\nURL: https://mariadb.com/kb/en/wsrep_last_seen_gtid/','','https://mariadb.com/kb/en/wsrep_last_seen_gtid/'),
(812,'WSREP_LAST_WRITTEN_GTID',44,'MariaDB starting with 10.4.2\n----------------------------\nWSREP_LAST_WRITTEN_GTID was added as part of Galera 4 in MariaDB 10.4.2.\n\nSyntax\n------\n\nWSREP_LAST_WRITTEN_GTID()\n\nDescription\n-----------\n\nReturns the Global Transaction ID of the most recent write transaction\nperformed by the client.\n\nURL: https://mariadb.com/kb/en/wsrep_last_written_gtid/','','https://mariadb.com/kb/en/wsrep_last_written_gtid/'),
(814,'System-Versioned Tables',45,'MariaDB supports temporal data tables in the form of system-versioning tables\n(allowing you to query and operate on historic data, discussed below),\napplication-time periods (allow you to query and operate on a temporal range\nof data), and bitemporal tables (which combine both system-versioning and\napplication-time periods).\n\nSystem-Versioned Tables\n-----------------------\n\nSystem-versioned tables store the history of all changes, not only data which\nis currently valid. This allows data analysis for any point in time, auditing\nof changes and comparison of data from different points in time. Typical uses\ncases are:\n\n* Forensic analysis & legal requirements to store data for N years.\n* Data analytics (retrospective, trends etc.), e.g. to get your staff\ninformation as of one year ago.\n* Point-in-time recovery - recover a table state as of particular point in\ntime.\n\nSystem-versioned tables were first introduced in the SQL:2011 standard.\n\nCreating a System-Versioned Table\n---------------------------------\n\nThe CREATE TABLE syntax has been extended to permit creating a\nsystem-versioned table. To be system-versioned, according to SQL:2011, a table\nmust have two generated columns, a period, and a special table option clause:\n\nCREATE TABLE t(\n x INT,\n start_timestamp TIMESTAMP(6) GENERATED ALWAYS AS ROW START,\n end_timestamp TIMESTAMP(6) GENERATED ALWAYS AS ROW END,\n PERIOD FOR SYSTEM_TIME(start_timestamp, end_timestamp)\n) WITH SYSTEM VERSIONING;\n\nIn MariaDB one can also use a simplified syntax:\n\nCREATE TABLE t (\n x INT\n) WITH SYSTEM VERSIONING;\n\nIn the latter case no extra columns will be created and they won\'t clutter the\noutput of, say, SELECT * FROM t. The versioning information will still be\nstored, and it can be accessed via the pseudo-columns ROW_START and ROW_END:\n\nSELECT x, ROW_START, ROW_END FROM t;\n\nAdding or Removing System Versioning To/From a Table\n----------------------------------------------------\n\nAn existing table can be altered to enable system versioning for it.\n\nCREATE TABLE t(\n x INT\n);\n\nALTER TABLE t ADD SYSTEM VERSIONING;\n\nSHOW CREATE TABLE t\\G\n*************************** 1. row ***************************\n   Table: t\nCreate Table: CREATE TABLE `t` (\n `x` int(11) DEFAULT NULL\n) ENGINE=InnoDB DEFAULT CHARSET=latin1 WITH SYSTEM VERSIONING\n\nSimilarly, system versioning can be removed from a table:\n\nALTER TABLE t DROP SYSTEM VERSIONING;\n\nSHOW CREATE TABLE t\\G\n*************************** 1. row ***************************\n   Table: t\nCreate Table: CREATE TABLE `t` (\n `x` int(11) DEFAULT NULL\n) ENGINE=InnoDB DEFAULT CHARSET=latin1\n\nOne can also add system versioning with all columns created explicitly:\n\nALTER TABLE t ADD COLUMN ts TIMESTAMP(6) GENERATED ALWAYS AS ROW START,\n       ADD COLUMN te TIMESTAMP(6) GENERATED ALWAYS AS ROW END,\n       ADD PERIOD FOR SYSTEM_TIME(ts, te),\n       ADD SYSTEM VERSIONING;\n\nSHOW CREATE TABLE t\\G\n*************************** 1. row ***************************\n   Table: t\nCreate Table: CREATE TABLE `t` (\n `x` int(11) DEFAULT NULL,\n `ts` timestamp(6) GENERATED ALWAYS AS ROW START,\n `te` timestamp(6) GENERATED ALWAYS AS ROW END,\n PERIOD FOR SYSTEM_TIME (`ts`, `te`)\n) ENGINE=InnoDB DEFAULT CHARSET=latin1 WITH SYSTEM VERSIONING\n\nInserting Data\n--------------\n\nWhen data is inserted into a system-versioned table, it is given a row_start\nvalue of the current timestamp, and a row_end value of\nFROM_UNIXTIME(2147483647.999999). The current timestamp can be adjusted by\nsetting the timestamp system variable, for example:\n\nSELECT NOW();\n+---------------------+\n| NOW()               |\n+---------------------+\n| 2022-10-24 23:09:38 |\n+---------------------+\n\nINSERT INTO t VALUES(1);\n\nSET @@timestamp = UNIX_TIMESTAMP(\'2033-10-24\');\n\nINSERT INTO t VALUES(2);\n\nSET @@timestamp = default;\n\nINSERT INTO t VALUES(3);\n\nSELECT a,row_start,row_end FROM t;\n+------+----------------------------+----------------------------+\n| a    | row_start                  | row_end                    |\n+------+----------------------------+----------------------------+\n|    1 | 2022-10-24 23:09:38.951347 | 2038-01-19 05:14:07.999999 |\n|    2 | 2033-10-24 00:00:00.000000 | 2038-01-19 05:14:07.999999 |\n|    3 | 2022-10-24 23:09:38.961857 | 2038-01-19 05:14:07.999999 |\n+------+----------------------------+----------------------------+\n\nQuerying Historical Data\n------------------------\n\nSELECT\n------\n\nTo query the historical data one uses the clause FOR SYSTEM_TIME directly\nafter the table name (before the table alias, if any). SQL:2011 provides three\nsyntactic extensions:\n\n* AS OF is used to see the table as it was at a specific point in time in the\npast:\n\nSELECT * FROM t FOR SYSTEM_TIME AS OF TIMESTAMP\'2016-10-09 08:07:06\';\n\n* BETWEEN start AND end will show all rows that were visible at any point\nbetween two specified points in time. It works inclusively, a row visible\nexactly at start or exactly at end will be shown too.\n\nSELECT * FROM t FOR SYSTEM_TIME BETWEEN (NOW() - INTERVAL 1 YEAR) AND NOW();\n\n* FROM start TO end will also show all rows that were visible at any point\nbetween two specified points in time, including start, but excluding end.\n\nSELECT * FROM t FOR SYSTEM_TIME FROM \'2016-01-01 00:00:00\' TO \'2017-01-01\n00:00:00\';\n\nAdditionally MariaDB implements a non-standard extension:\n\n* ALL will show all rows, historical and current.\n\nSELECT * FROM t FOR SYSTEM_TIME ALL;\n\nIf the FOR SYSTEM_TIME clause is not used, the table will show the current\ndata. This is usually the same as if one had specified FOR SYSTEM_TIME AS OF\nCURRENT_TIMESTAMP, unless one has adjusted the row_start value (until MariaDB\n10.11, only possible by setting the secure_timestamp variable). For example:\n\nCREATE OR REPLACE TABLE t (a int) WITH SYSTEM VERSIONING;\n\nSELECT NOW();\n+---------------------+\n| NOW()               |\n+---------------------+\n| 2022-10-24 23:43:37 |\n+---------------------+\n\nINSERT INTO t VALUES (1);\n\nSET @@timestamp = UNIX_TIMESTAMP(\'2033-03-03\');\n\nINSERT INTO t VALUES (2);\n\nDELETE FROM t;\n\nSET @@timestamp = default;\n\nSELECT a, row_start, row_end FROM t FOR SYSTEM_TIME ALL;\n+------+----------------------------+----------------------------+\n| a    | row_start                  | row_end                    |\n+------+----------------------------+----------------------------+\n|    1 | 2022-10-24 23:43:37.192725 | 2033-03-03 00:00:00.000000 |\n|    2 | 2033-03-03 00:00:00.000000 | 2033-03-03 00:00:00.000000 |\n+------+----------------------------+----------------------------+\n2 rows in set (0.000 sec)\n\nSELECT a, row_start, row_end FROM t FOR SYSTEM_TIME AS OF CURRENT_TIMESTAMP;\n+------+----------------------------+----------------------------+\n| a    | row_start                  | row_end                    |\n+------+----------------------------+----------------------------+\n|    1 | 2022-10-24 23:43:37.192725 | 2033-03-03 00:00:00.000000 |\n+------+----------------------------+----------------------------+\n1 row in set (0.000 sec)\n\nSELECT a, row_start, row_end FROM t;\nEmpty set (0.001 sec)\n\nViews and Subqueries\n--------------------\n\nWhen a system-versioned tables is used in a view or in a subquery in the from\nclause, FOR SYSTEM_TIME can be used directly in the view or subquery body, or\n(non-standard) applied to the whole view when it\'s being used in a SELECT:\n\nCREATE VIEW v1 AS SELECT * FROM t FOR SYSTEM_TIME AS OF TIMESTAMP\'2016-10-09\n08:07:06\';\n\nOr\n\nCREATE VIEW v1 AS SELECT * FROM t;\nSELECT * FROM v1 FOR SYSTEM_TIME AS OF TIMESTAMP\'2016-10-09 08:07:06\';\n\nUse in Replication and Binary Logs\n----------------------------------\n\nTables that use system-versioning implicitly add the row_end column to the\nPrimary Key. While this is generally not an issue for most use cases, it can\nlead to problems when re-applying write statements from the binary log or in\nreplication environments, where a primary retries an SQL statement on the\nreplica.\n\nSpecifically, these writes include a value on the row_end column containing\nthe timestamp from when the write was initially made. The re-occurrence of the\nPrimary Key with the old system-versioning columns raises an error due to the\nduplication.\n\nTo mitigate this with MariaDB Replication, set the secure_timestamp system\nvariable to YES on the replica. When set, the replica uses its own system\nclock when applying to the row log, meaning that the primary can retry as many\ntimes as needed without causing a conflict. The retries generate new\nhistorical rows with new values for the row_start and row_end columns.\n\nTransaction-Precise History in InnoDB\n-------------------------------------\n\nA point in time when a row was inserted or deleted does not necessarily mean\nthat a change became visible at the same moment. With transactional tables, a\nrow might have been inserted in a long transaction, and became visible hours\nafter it was inserted.\n\nFor some applications — for example, when doing data analytics on one-year-old\ndata — this distinction does not matter much. For others — forensic analysis —\nit might be crucial.\n\nMariaDB supports transaction-precise history (only for the InnoDB storage\nengine) that allows seeing the data exactly as it would\'ve been seen by a new\nconnection doing a SELECT at the specified point in time — rows inserted\nbefore that point, but committed after will not be shown.\n\nTo use transaction-precise history, InnoDB needs to remember not timestamps,\nbut transaction identifier per row. This is done by creating generated columns\nas BIGINT UNSIGNED, not TIMESTAMP(6):\n\nCREATE TABLE t(\n x INT,\n start_trxid BIGINT UNSIGNED GENERATED ALWAYS AS ROW START,\n end_trxid BIGINT UNSIGNED GENERATED ALWAYS AS ROW END,\n PERIOD FOR SYSTEM_TIME(start_trxid, end_trxid)\n) WITH SYSTEM VERSIONING;\n\nThese columns must be specified explicitly, but they can be made INVISIBLE to\navoid cluttering SELECT * output.\n\nWhen one uses transaction-precise history, one can optionally use transaction\nidentifiers in the FOR SYSTEM_TIME clause:\n\nSELECT * FROM t FOR SYSTEM_TIME AS OF TRANSACTION 12345;\n\nThis will show the data, exactly as it was seen by the transaction with the\nidentifier 12345.\n\nStoring the History Separately\n------------------------------\n\nWhen the history is stored together with the current data, it increases the\nsize of the table, so current data queries — table scans and index searches —\nwill take more time, because they will need to skip over historical data. If\nmost queries on that table use only current data, it might make sense to store\nthe history separately, to reduce the overhead from versioning.\n\nThis is done by partitioning the table by SYSTEM_TIME. Because of the\npartition pruning optimization, all current data queries will only access one\npartition, the one that stores current data.\n\nThis example shows how to create such a partitioned table:\n\nCREATE TABLE t (x INT) WITH SYSTEM VERSIONING\n PARTITION BY SYSTEM_TIME (\n  PARTITION p_hist HISTORY,\n  PARTITION p_cur CURRENT\n );\n\nIn this example all history will be stored in the partition p_hist while all\ncurrent data will be in the partition p_cur. The table must have exactly one\ncurrent partition and at least one historical partition.\n\nPartitioning by SYSTEM_TIME also supports automatic partition rotation. One\ncan rotate historical partitions by time or by size. This example shows how to\nrotate partitions by size:\n\nCREATE TABLE t (x INT) WITH SYSTEM VERSIONING\n PARTITION BY SYSTEM_TIME LIMIT 100000 (\n  PARTITION p0 HISTORY,\n  PARTITION p1 HISTORY,\n  PARTITION pcur CURRENT\n );\n\nMariaDB will start writing history rows into partition p0, and when it reaches\na size of 100000 rows, MariaDB will switch to partition p1. There are only two\nhistorical partitions, so when p1 overflows, MariaDB will issue a warning, but\nwill continue writing into it.\n\nSimilarly, one can rotate partitions by time:\n\nCREATE TABLE t (x INT) WITH SYSTEM VERSIONING\n PARTITION BY SYSTEM_TIME INTERVAL 1 WEEK (\n  PARTITION p0 HISTORY,\n  PARTITION p1 HISTORY,\n  PARTITION p2 HISTORY,\n  PARTITION pcur CURRENT\n );\n\nThis means that the history for the first week after the table was created\nwill be stored in p0. The history for the second week — in p1, and all later\nhistory will go into p2. One can see the exact rotation time for each\npartition in the INFORMATION_SCHEMA.PARTITIONS table.\n\nIt is possible to combine partitioning by SYSTEM_TIME and subpartitions:\n\nCREATE TABLE t (x INT) WITH SYSTEM VERSIONING\n PARTITION BY SYSTEM_TIME\n  SUBPARTITION BY KEY (x)\n  SUBPARTITIONS 4 (\n  PARTITION ph HISTORY,\n  PARTITION pc CURRENT\n );\n\nDefault Partitions\n------------------\n\nMariaDB starting with 10.5.0\n----------------------------\nSince partitioning by current and historical data is such a typical usecase,\nfrom MariaDB 10.5, it is possible to use a simplified statement to do so. For\nexample, instead of\n\nCREATE TABLE t (x INT) WITH SYSTEM VERSIONING \n PARTITION BY SYSTEM_TIME (\n  PARTITION p0 HISTORY,\n  PARTITION pn CURRENT\n);\n\nyou can use\n\nCREATE TABLE t (x INT) WITH SYSTEM VERSIONING \n PARTITION BY SYSTEM_TIME;\n\nYou can also specify the number of partitions, which is useful if you want to\nrotate history by time, for example:\n\nCREATE TABLE t (x INT) WITH SYSTEM VERSIONING \n PARTITION BY SYSTEM_TIME\n  INTERVAL 1 MONTH\n  PARTITIONS 12;\n\nSpecifying the number of partitions without specifying a rotation condition\nwill result in a warning:\n\nCREATE OR REPLACE TABLE t (x INT) WITH SYSTEM VERSIONING\n PARTITION BY SYSTEM_TIME PARTITIONS 12;\nQuery OK, 0 rows affected, 1 warning (0.518 sec)\n\nWarning (Code 4115): Maybe missing parameters: no rotation condition for\nmultiple HISTORY partitions.\n\nwhile specifying only 1 partition will result in an error:\n\nCREATE OR REPLACE TABLE t (x INT) WITH SYSTEM VERSIONING\n PARTITION BY SYSTEM_TIME PARTITIONS 1;\nERROR 4128 (HY000): Wrong partitions for `t`: must have at least one HISTORY\nand exactly one last CURRENT\n\nAutomatically Creating Partitions\n---------------------------------\n\nMariaDB starting with 10.9.1\n----------------------------\nFrom MariaDB 10.9.1, the AUTO keyword can be used to automatically create\nhistory partitions.\n\nFor example\n\nCREATE TABLE t1 (x int) WITH SYSTEM VERSIONING\n  PARTITION BY SYSTEM_TIME INTERVAL 1 HOUR AUTO;\n\nCREATE TABLE t1 (x int) WITH SYSTEM VERSIONING\n PARTITION BY SYSTEM_TIME INTERVAL 1 MONTH\n STARTS \'2021-01-01 00:00:00\' AUTO PARTITIONS 12;\n\nCREATE TABLE t1 (x int) WITH SYSTEM VERSIONING\n PARTITION BY SYSTEM_TIME LIMIT 1000 AUTO;\n\nOr with explicit partitions:\n\nCREATE TABLE t1 (x int) WITH SYSTEM VERSIONING\n PARTITION BY SYSTEM_TIME INTERVAL 1 HOUR AUTO\n (PARTITION p0 HISTORY, PARTITION pn CURRENT);\n\nTo disable or enable auto-creation one can use ALTER TABLE by adding or\nremoving AUTO from the partitioning specification:\n\nCREATE TABLE t1 (x int) WITH SYSTEM VERSIONING\n PARTITION BY SYSTEM_TIME INTERVAL 1 HOUR AUTO;\n\n# Disables auto-creation:\nALTER TABLE t1 PARTITION BY SYSTEM_TIME INTERVAL 1 HOUR;\n\n# Enables auto-creation:\nALTER TABLE t1 PARTITION BY SYSTEM_TIME INTERVAL 1 HOUR AUTO;\n\nIf the rest of the partitioning specification is identical to CREATE TABLE, no\nrepartitioning will be done (for details see MDEV-27328).\n\nRemoving Old History\n--------------------\n\nBecause it stores all the history, a system-versioned table might grow very\nlarge over time. There are many options to trim down the space and remove the\nold history.\n\nOne can completely drop the versioning from the table and add it back again,\nthis will delete all the history:\n\nALTER TABLE t DROP SYSTEM VERSIONING;\nALTER TABLE t ADD SYSTEM VERSIONING;\n\nIt might be a rather time-consuming operation, though, as the table will need\nto be rebuilt, possibly twice (depending on the storage engine).\n\nAnother option would be to use partitioning and drop some of historical\npartitions:\n\nALTER TABLE t DROP PARTITION p0;\n\nNote, that one cannot drop a current partition or the only historical\npartition.\n\nAnd the third option; one can use a variant of the DELETE statement to prune\nthe history:\n\nDELETE HISTORY FROM t;\n\nor only old history up to a specific point in time:\n\nDELETE HISTORY FROM t BEFORE SYSTEM_TIME \'2016-10-09 08:07:06\';\n\nor to a specific transaction (with BEFORE SYSTEM_TIME TRANSACTION xxx).\n\nTo protect the integrity of the history, this statement requires a special\nDELETE HISTORY privilege.\n\nCurrently, using the DELETE HISTORY statement with a BEFORE SYSTEM_TIME\ngreater than the ROW_END of the active records (as a TIMESTAMP, this has a\nmaximum value of \'2038-01-19 03:14:07\' UTC) will result in the historical\nrecords being dropped, and the active records being deleted and moved to\nhistory. See MDEV-25468.\n\nPrior to MariaDB 10.4.5, the TRUNCATE TABLE statement drops all historical\nrecords from a system-versioned-table.\n\nFrom MariaDB 10.4.5, historic data is protected from TRUNCATE statements, as\nper the SQL standard, and an Error 4137 is instead raised:\n\nTRUNCATE t;\nERROR 4137 (HY000): System-versioned tables do not support TRUNCATE TABLE\n\nExcluding Columns From Versioning\n---------------------------------\n\nAnother MariaDB extension allows to version only a subset of columns in a\ntable. This is useful, for example, if you have a table with user information\nthat should be versioned, but one column is, let\'s say, a login counter that\nis incremented often and is not interesting to version. Such a column can be\nexcluded from versioning by declaring it WITHOUT VERSIONING\n\nCREATE TABLE t (\n x INT,\n y INT WITHOUT SYSTEM VERSIONING\n) WITH SYSTEM VERSIONING;\n\nA column can also be declared WITH VERSIONING, that will automatically make\nthe table versioned. The statement below is equivalent to the one above:\n\nCREATE TABLE t (\n x INT WITH SYSTEM VERSIONING,\n y INT\n);\n\nChanges in other sections: https://mariadb.com/kb/en/create-table/\nhttps://mariadb.com/kb/en/alter-table/ https://mariadb.com/kb/en/join-syntax/\nhttps://mariadb.com/kb/en/partitioning-types-overview/\nhttps://mariadb.com/kb/en/date-and-time-units/\nhttps://mariadb.com/kb/en/delete/ https://mariadb.com/kb/en/grant/\n\nthey all reference back to this page\n\nAlso, TODO:\n\n* limitations (size, speed, adding history to unique not nullable columns)\n\nSystem Variables\n----------------\n\nThere are a number of system variables related to system-versioned tables:\n\nsystem_versioning_alter_history\n-------------------------------\n\n* Description: SQL:2011 does not allow ALTER TABLE on system-versioned tables.\nWhen this variable is set to ERROR, an attempt to alter a system-versioned\ntable will result in an error. When this variable is set to KEEP, ALTER TABLE\nwill be allowed, but the history will become incorrect — querying historical\ndata will show the new table structure. This mode is still useful, for\nexample, when adding new columns to a table. Note that if historical data\ncontains or would contain nulls, attempting to ALTER these columns to be NOT\nNULL will return an error (or warning if strict_mode is not set).\n* Commandline: --system-versioning-alter-history=value\n* Scope: Global, Session\n* Dynamic: Yes\n* Type: Enum\n* Default Value: ERROR\n* Valid Values: ERROR, KEEP\n\nsystem_versioning_asof\n----------------------\n\n* Description: If set to a specific timestamp value, an implicit FOR\nSYSTEM_TIME AS OF clause will be applied to all queries. This is useful if one\nwants to do many queries for history at the specific point in time. Set it to\nDEFAULT to restore the default behavior. Has no effect on DML, so queries such\nas INSERT .. SELECT and REPLACE .. SELECT need to state AS OF explicitly.\n* Commandline: None\n* Scope: Global, Session\n* Dynamic: Yes\n* Type: Varchar\n* Default Value: DEFAULT\n\nsystem_versioning_innodb_algorithm_simple\n-----------------------------------------\n\n* Description: Never fully implemented and removed in the following release.\n* Commandline: --system-versioning-innodb-algorithm-simple[={0|1}]\n* Scope: Global, Session\n* Dynamic: Yes\n* Type: Boolean\n* Default Value: ON\n* Introduced: MariaDB 10.3.4\n* Removed: MariaDB 10.3.5\n\nsystem_versioning_insert_history\n--------------------------------\n\n* Description: Allows direct inserts into ROW_START and ROW_END columns if\nsecure_timestamp allows changing timestamp.\n* Commandline: --system-versioning-insert-history[={0|1}]\n* Scope: Global, Session\n* Dynamic: Yes\n* Type: Boolean\n* Default Value: OFF\n* Introduced: MariaDB 10.11.0\n\nLimitations\n-----------\n\n* Versioning clauses can not be applied to generated (virtual and persistent)\ncolumns.\n* Before MariaDB 10.11, mariadb-dump did not read historical rows from\nversioned tables, and so historical data would not be backed up. Also, a\nrestore of the timestamps would not be possible as they cannot be defined by\nan insert/a user. From MariaDB 10.11, use the -H or --dump-history options to\ninclude the history.\n\nURL: https://mariadb.com/kb/en/system-versioned-tables/','','https://mariadb.com/kb/en/system-versioned-tables/'),
(815,'Application-Time Periods',45,'MariaDB starting with 10.4.3\n----------------------------\nSupport for application-time period-versioning was added in MariaDB 10.4.3.\n\nExtending system-versioned tables, MariaDB 10.4 supports application-time\nperiod tables. Time periods are defined by a range between two temporal\ncolumns. The columns must be of the same temporal data type, i.e. DATE,\nTIMESTAMP or DATETIME (TIME and YEAR are not supported), and of the same width.\n\nUsing time periods implicitly defines the two columns as NOT NULL. It also\nadds a constraint to check whether the first value is less than the second\nvalue. The constraint is invisible to SHOW CREATE TABLE statements. The name\nof this constraint is prefixed by the time period name, to avoid conflict with\nother constraints.\n\nCreating Tables with Time Periods\n---------------------------------\n\nTo create a table with a time period, use a CREATE TABLE statement with the\nPERIOD table option.\n\nCREATE TABLE t1(\n name VARCHAR(50),\n date_1 DATE,\n date_2 DATE,\n PERIOD FOR date_period(date_1, date_2));\n\nThis creates a table with a time_period period and populates the table with\nsome basic temporal values.\n\nExamples are available in the MariaDB Server source code, at\nmysql-test/suite/period/r/create.result.\n\nAdding and Removing Time Periods\n--------------------------------\n\nThe ALTER TABLE statement now supports syntax for adding and removing time\nperiods from a table. To add a period, use the ADD PERIOD clause.\n\nFor example:\n\nCREATE OR REPLACE TABLE rooms (\n room_number INT,\n guest_name VARCHAR(255),\n checkin DATE,\n checkout DATE\n );\n\nALTER TABLE rooms ADD PERIOD FOR p(checkin,checkout);\n\nTo remove a period, use the DROP PERIOD clause:\n\nALTER TABLE rooms DROP PERIOD FOR p;\n\nBoth ADD PERIOD and DROP PERIOD clauses include an option to handle whether\nthe period already exists:\n\nALTER TABLE rooms ADD PERIOD IF NOT EXISTS FOR p(checkin,checkout);\n\nALTER TABLE rooms DROP PERIOD IF EXISTS FOR p;\n\nDeletion by Portion\n-------------------\n\nYou can also remove rows that fall within certain time periods.\n\nWhen MariaDB executes a DELETE FOR PORTION statement, it removes the row:\n\n* When the row period falls completely within the delete period, it removes\nthe row.\n* When the row period overlaps the delete period, it shrinks the row, removing\nthe overlap from the first or second row period value.\n* When the delete period falls completely within the row period, it splits the\nrow into two rows.  The first row runs from the starting row period to the\nstarting delete period.  The second runs from the ending delete period to the\nending row period.\n\nTo test this, first populate the table with some data to operate on:\n\nCREATE TABLE t1(\n name VARCHAR(50),\n date_1 DATE,\n date_2 DATE,\n PERIOD FOR date_period(date_1, date_2));\n\nINSERT INTO t1 (name, date_1, date_2) VALUES\n  (\'a\', \'1999-01-01\', \'2000-01-01\'),\n  (\'b\', \'1999-01-01\', \'2018-12-12\'),\n  (\'c\', \'1999-01-01\', \'2017-01-01\'),\n  (\'d\', \'2017-01-01\', \'2019-01-01\');\n\nSELECT * FROM t1;\n+------+------------+------------+\n| name | date_1     | date_2     |\n+------+------------+------------+\n| a    | 1999-01-01 | 2000-01-01 |\n| b    | 1999-01-01 | 2018-12-12 |\n| c    | 1999-01-01 | 2017-01-01 |\n| d    | 2017-01-01 | 2019-01-01 |\n+------+------------+------------+\n\nThen, run the DELETE FOR PORTION statement:\n\nDELETE FROM t1\nFOR PORTION OF date_period\n  FROM \'2001-01-01\' TO \'2018-01-01\';\nQuery OK, 3 rows affected (0.028 sec)\n\nSELECT * FROM t1 ORDER BY name;\n+------+------------+------------+\n| name | date_1     | date_2     |\n+------+------------+------------+\n| a    | 1999-01-01 | 2000-01-01 |\n| b    | 1999-01-01 | 2001-01-01 |\n| b    | 2018-01-01 | 2018-12-12 |\n| c    | 1999-01-01 | 2001-01-01 |\n| d    | 2018-01-01 | 2019-01-01 |\n+------+------------+------------+\n\nHere:\n\n* a is unchanged, as the range falls entirely out of the specified portion to\nbe deleted.\n* b, with values ranging from 1999 to 2018, is split into two rows, 1999 to\n2000 and 2018-01 to 2018-12.\n* c, with values ranging from 1999 to 2017, where only the upper value falls\nwithin the portion to be deleted, has been shrunk to 1999 to 2001.\n* d, with values ranging from 2017 to 2019, where only the lower value falls\nwithin the portion to be deleted, has been shrunk to 2018 to 2019.\n\nThe DELETE FOR PORTION statement has the following restrictions\n\n* The FROM...TO clause must be constant\n* Multi-delete is not supported\n\nIf there are DELETE or INSERT triggers, it works as follows: any matched row\nis deleted, and then one or two rows are inserted. If the record is deleted\ncompletely, nothing is inserted.\n\nUpdating by Portion\n-------------------\n\nThe UPDATE syntax now supports UPDATE FOR PORTION, which modifies rows based\non their occurrence in a range:\n\nTo test it, first populate the table with some data:\n\nTRUNCATE t1;\n\nINSERT INTO t1 (name, date_1, date_2) VALUES\n  (\'a\', \'1999-01-01\', \'2000-01-01\'),\n  (\'b\', \'1999-01-01\', \'2018-12-12\'),\n  (\'c\', \'1999-01-01\', \'2017-01-01\'),\n  (\'d\', \'2017-01-01\', \'2019-01-01\');\n\nSELECT * FROM t1;\n+------+------------+------------+\n| name | date_1     | date_2     |\n+------+------------+------------+\n| a    | 1999-01-01 | 2000-01-01 |\n| b    | 1999-01-01 | 2018-12-12 |\n| c    | 1999-01-01 | 2017-01-01 |\n| d    | 2017-01-01 | 2019-01-01 |\n+------+------------+------------+\n\nThen run the update:\n\nUPDATE t1 FOR PORTION OF date_period\n FROM \'2000-01-01\' TO \'2018-01-01\'\nSET name = CONCAT(name,\'_original\');\n\nSELECT * FROM t1 ORDER BY name;\n+------------+------------+------------+\n| name       | date_1     | date_2     |\n+------------+------------+------------+\n| a          | 1999-01-01 | 2000-01-01 |\n| b          | 1999-01-01 | 2000-01-01 |\n| b          | 2018-01-01 | 2018-12-12 |\n| b_original | 2000-01-01 | 2018-01-01 |\n| c          | 1999-01-01 | 2000-01-01 |\n| c_original | 2000-01-01 | 2017-01-01 |\n| d          | 2018-01-01 | 2019-01-01 |\n| d_original | 2017-01-01 | 2018-01-01 |\n+------------+------------+------------+\n\n* a is unchanged, as the range falls entirely out of the specified portion to\nbe deleted.\n* b, with values ranging from 1999 to 2018, is split into two rows, 1999 to\n2000 and 2018-01 to 2018-12.\n* c, with values ranging from 1999 to 2017, where only the upper value falls\nwithin the portion to be deleted, has been shrunk to 1999 to 2001.\n* d, with values ranging from 2017 to 2019, where only the lower value falls\nwithin the portion to be deleted, has been shrunk to 2018 to 2019. \n* Original rows affected by the update have \"_original\" appended to the name.\n\nThe UPDATE FOR PORTION statement has the following limitations:\n\n* The operation cannot modify the two temporal columns used by the time period\n* The operation cannot reference period values in the SET expression\n* FROM...TO expressions must be constant\n\nWITHOUT OVERLAPS\n----------------\n\nMariaDB starting with 10.5.3\n----------------------------\nMariaDB 10.5 introduced a new clause, WITHOUT OVERLAPS, which allows one to\ncreate an index specifying that application time periods should not overlap.\n\nAn index constrained by WITHOUT OVERLAPS is required to be either a primary\nkey or a unique index.\n\nTake the following example, an application time period table for a booking\nsystem:\n\nCREATE OR REPLACE TABLE rooms (\n room_number INT,\n guest_name VARCHAR(255),\n checkin DATE,\n checkout DATE,\n PERIOD FOR p(checkin,checkout)\n );\n\nINSERT INTO rooms VALUES \n (1, \'Regina\', \'2020-10-01\', \'2020-10-03\'),\n (2, \'Cochise\', \'2020-10-02\', \'2020-10-05\'),\n (1, \'Nowell\', \'2020-10-03\', \'2020-10-07\'),\n (2, \'Eusebius\', \'2020-10-04\', \'2020-10-06\');\n\nOur system is not intended to permit overlapping bookings, so the fourth\nrecord above should not have been inserted. Using WITHOUT OVERLAPS in a unique\nindex (in this case based on a combination of room number and the application\ntime period) allows us to specify this constraint in the table definition.\n\nCREATE OR REPLACE TABLE rooms (\n room_number INT,\n guest_name VARCHAR(255),\n checkin DATE,\n checkout DATE,\n PERIOD FOR p(checkin,checkout),\n UNIQUE (room_number, p WITHOUT OVERLAPS)\n );\n\nINSERT INTO rooms VALUES \n (1, \'Regina\', \'2020-10-01\', \'2020-10-03\'),\n (2, \'Cochise\', \'2020-10-02\', \'2020-10-05\'),\n (1, \'Nowell\', \'2020-10-03\', \'2020-10-07\'),\n (2, \'Eusebius\', \'2020-10-04\', \'2020-10-06\');\nERROR 1062 (23000): Duplicate entry \'2-2020-10-06-2020-10-04\' for key\n\'room_number\'\n\nFurther Examples\n----------------\n\nThe implicit change from NULL to NOT NULL:\n\nCREATE TABLE `t2` (\n `id` int(11) DEFAULT NULL,\n `d1` datetime DEFAULT NULL,\n `d2` datetime DEFAULT NULL\n) ENGINE=InnoDB DEFAULT CHARSET=latin1;\n\nALTER TABLE t2 ADD PERIOD FOR p(d1,d2);\n\nSHOW CREATE TABLE t2\\G\n*************************** 1. row ***************************\n   Table: t2\nCreate Table: CREATE TABLE `t2` (\n `id` int(11) DEFAULT NULL,\n `d1` datetime NOT NULL,\n `d2` datetime NOT NULL,\n PERIOD FOR `p` (`d1`, `d2`)\n) ENGINE=InnoDB DEFAULT CHARSET=latin1\n\nDue to this constraint, trying to add a time period where null data already\nexists will fail.\n\nCREATE OR REPLACE TABLE `t2` (\n `id` int(11) DEFAULT NULL,\n `d1` datetime DEFAULT NULL,\n `d2` datetime DEFAULT NULL\n) ENGINE=InnoDB DEFAULT CHARSET=latin1;\n\nINSERT INTO t2(id) VALUES(1);\n\nALTER TABLE t2 ADD PERIOD FOR p(d1,d2);\nERROR 1265 (01000): Data truncated for column \'d1\' at row 1\n\nURL: https://mariadb.com/kb/en/application-time-periods/','','https://mariadb.com/kb/en/application-time-periods/'),
(817,'ST_AsGeoJSON',46,'Syntax\n------\n\nST_AsGeoJSON(g[, max_decimals[, options]])\n\nDescription\n-----------\n\nReturns the given geometry g as a GeoJSON element. The optional max_decimals\nlimits the maximum number of decimals displayed.\n\nThe optional options flag can be set to 1 to add a bounding box to the output.\n\nExamples\n--------\n\nSELECT ST_AsGeoJSON(ST_GeomFromText(\'POINT(5.3 7.2)\'));\n+-------------------------------------------------+\n| ST_AsGeoJSON(ST_GeomFromText(\'POINT(5.3 7.2)\')) |\n+-------------------------------------------------+\n| {\"type\": \"Point\", \"coordinates\": [5.3, 7.2]}    |\n+-------------------------------------------------+\n\nURL: https://mariadb.com/kb/en/geojson-st_asgeojson/','','https://mariadb.com/kb/en/geojson-st_asgeojson/'),
(820,'Addition Operator (+)',48,'Syntax\n------\n\n+\n\nDescription\n-----------\n\nAddition.\n\nIf both operands are integers, the result is calculated with BIGINT precision.\nIf either integer is unsigned, the result is also an unsigned integer.\n\nFor real or string operands, the operand with the highest precision determines\nthe result precision.\n\nExamples\n--------\n\nSELECT 3+5;\n+-----+\n| 3+5 |\n+-----+\n|   8 |\n+-----+\n\nURL: https://mariadb.com/kb/en/addition-operator/','','https://mariadb.com/kb/en/addition-operator/'),
(314,'SIGNAL',24,'Syntax\n------\n\nSIGNAL error_condition\n  [SET error_property\n  [, error_property] ...]\n\nerror_condition:\n  SQLSTATE [VALUE] \'sqlstate_value\'\n | condition_name\n\nerror_property:\n  error_property_name = <error_property_value>\n\nerror_property_name:\n  CLASS_ORIGIN\n | SUBCLASS_ORIGIN\n | MESSAGE_TEXT\n | MYSQL_ERRNO\n | CONSTRAINT_CATALOG\n | CONSTRAINT_SCHEMA\n | CONSTRAINT_NAME\n | CATALOG_NAME\n | SCHEMA_NAME\n | TABLE_NAME\n | COLUMN_NAME\n | CURSOR_NAME\n\nSIGNAL empties the diagnostics area and produces a custom error. This\nstatement can be used anywhere, but is generally useful when used inside a\nstored program. When the error is produced, it can be caught by a HANDLER. If\nnot, the current stored program, or the current statement, will terminate with\nthe specified error.\n\nSometimes an error HANDLER just needs to SIGNAL the same error it received,\noptionally with some changes. Usually the RESIGNAL statement is the most\nconvenient way to do this.\n\nerror_condition can be an SQLSTATE value or a named error condition defined\nvia DECLARE CONDITION. SQLSTATE must be a constant string consisting of five\ncharacters. These codes are standard to ODBC and ANSI SQL. For customized\nerrors, the recommended SQLSTATE is \'45000\'. For a list of SQLSTATE values\nused by MariaDB, see the MariaDB Error Codes page. The SQLSTATE can be read\nvia the API method mysql_sqlstate( ).\n\nTo specify error properties user-defined variables and local variables can be\nused, as well as character set conversions (but you can\'t set a collation).\n\nThe error properties, their type and their default values are explained in the\ndiagnostics area page.\n\nErrors\n------\n\nIf the SQLSTATE is not valid, the following error like this will be produced:\n\nERROR 1407 (42000): Bad SQLSTATE: \'123456\'\n\nIf a property is specified more than once, an error like this will be produced:\n\nERROR 1641 (42000): Duplicate condition information item \'MESSAGE_TEXT\'\n\nIf you specify a condition name which is not declared, an error like this will\nbe produced:\n\nERROR 1319 (42000): Undefined CONDITION: cond_name\n\nIf MYSQL_ERRNO is out of range, you will get an error like this:\n\nERROR 1231 (42000): Variable \'MYSQL_ERRNO\' can\'t be set to the value of \'0\'\n\nExamples\n--------\n\nHere\'s what happens if SIGNAL is used in the client to generate errors:\n\nSIGNAL SQLSTATE \'01000\';\nQuery OK, 0 rows affected, 1 warning (0.00 sec)\n\nSHOW WARNINGS;\n\n+---------+------+------------------------------------------+\n| Level   | Code | Message                                  |\n+---------+------+------------------------------------------+\n| Warning | 1642 | Unhandled user-defined warning condition |\n+---------+------+------------------------------------------+\n1 row in set (0.06 sec)\n\nSIGNAL SQLSTATE \'02000\';\nERROR 1643 (02000): Unhandled user-defined not found condition\n\nHow to specify MYSQL_ERRNO and MESSAGE_TEXT properties:\n\nSIGNAL SQLSTATE \'45000\' SET MYSQL_ERRNO=30001, MESSAGE_TEXT=\'H\nello, world!\';\n\nERROR 30001 (45000): Hello, world!\n\nThe following code shows how to use user variables, local variables and\ncharacter set conversion with SIGNAL:\n\nCREATE PROCEDURE test_error(x INT)\nBEGIN\n DECLARE errno SMALLINT UNSIGNED DEFAULT 31001;\n SET @errmsg = \'Hello, world!\';\n IF x = 1 THEN\n   SIGNAL SQLSTATE \'45000\' SET\n   MYSQL_ERRNO = errno,\n   MESSAGE_TEXT = @errmsg;\n ELSE\n   SIGNAL SQLSTATE \'45000\' SET\n   MYSQL_ERRNO = errno,\n   MESSAGE_TEXT = _utf8\'Hello, world!\';\n END IF;\nEND;\n\nHow to use named error conditions:\n\nCREATE PROCEDURE test_error(n INT)\nBEGIN\n DECLARE `too_big` CONDITION FOR SQLSTATE \'45000\';\n IF n > 10 THEN\n   SIGNAL `too_big`;\n END IF;\nEND;\n\nIn this example, we\'ll define a HANDLER for an error code. When the error\noccurs, we SIGNAL a more informative error which makes sense for our procedure:\n\nCREATE PROCEDURE test_error()\nBEGIN\n DECLARE EXIT HANDLER\n FOR 1146\n BEGIN\n   SIGNAL SQLSTATE \'45000\' SET\n   MESSAGE_TEXT = \'Temporary tables not found; did you call init()\nprocedure?\';\n END;\n -- this will produce a 1146 error\n SELECT `c` FROM `temptab`;\nEND;\n\nURL: https://mariadb.com/kb/en/signal/','','https://mariadb.com/kb/en/signal/'),
(324,'LINESTRING',25,'Syntax\n------\n\nLineString(pt1,pt2,...)\n\nDescription\n-----------\n\nConstructs a WKB LineString value from a number of WKB Point arguments. If any\nargument is not a WKB Point, the return value is NULL. If the number of Point\narguments is less than two, the return value is NULL.\n\nExamples\n--------\n\nSET @ls = \'LineString(1 1,2 2,3 3)\';\n\nSELECT AsText(EndPoint(GeomFromText(@ls)));\n+-------------------------------------+\n| AsText(EndPoint(GeomFromText(@ls))) |\n+-------------------------------------+\n| POINT(3 3)                          |\n+-------------------------------------+\n\nCREATE TABLE gis_line  (g LINESTRING);\nINSERT INTO gis_line VALUES\n  (LineFromText(\'LINESTRING(0 0,0 10,10 0)\')),\n  (LineStringFromText(\'LINESTRING(10 10,20 10,20 20,10 20,10 10)\')),\n  (LineStringFromWKB(AsWKB(LineString(Point(10, 10), Point(40, 10)))));\n\nURL: https://mariadb.com/kb/en/linestring/','','https://mariadb.com/kb/en/linestring/'),
(822,'Modulo Operator (%)',48,'Syntax\n------\n\nN % M\n\nDescription\n-----------\n\nModulo operator. Returns the remainder of N divided by M. See also MOD.\n\nExamples\n--------\n\nSELECT 1042 % 50;\n+-----------+\n| 1042 % 50 |\n+-----------+\n|        42 |\n+-----------+\n\nURL: https://mariadb.com/kb/en/modulo-operator/','','https://mariadb.com/kb/en/modulo-operator/'),
(825,'CHANGE MASTER TO',49,'The terms master and slave have historically been used in replication, but the\nterms terms primary and replica are now preferred. The old terms are used\nstill used in parts of the documentation, and in MariaDB commands, although\nMariaDB 10.5 has begun the process of renaming. The documentation process is\nongoing. See MDEV-18777 to follow progress on this effort.\n\nSyntax\n------\n\nCHANGE MASTER [\'connection_name\'] TO master_def  [, master_def] ... \n [FOR CHANNEL \'channel_name\']\n\nmaster_def:\n  MASTER_BIND = \'interface_name\'\n | MASTER_HOST = \'host_name\'\n | MASTER_USER = \'user_name\'\n | MASTER_PASSWORD = \'password\'\n | MASTER_PORT = port_num\n | MASTER_CONNECT_RETRY = interval\n | MASTER_HEARTBEAT_PERIOD = interval\n | MASTER_LOG_FILE = \'master_log_name\'\n | MASTER_LOG_POS = master_log_pos\n | RELAY_LOG_FILE = \'relay_log_name\'\n | RELAY_LOG_POS = relay_log_pos\n | MASTER_DELAY = interval\n | MASTER_SSL = {0|1}\n | MASTER_SSL_CA = \'ca_file_name\'\n | MASTER_SSL_CAPATH = \'ca_directory_name\'\n | MASTER_SSL_CERT = \'cert_file_name\'\n | MASTER_SSL_CRL = \'crl_file_name\'\n | MASTER_SSL_CRLPATH = \'crl_directory_name\'\n | MASTER_SSL_KEY = \'key_file_name\'\n | MASTER_SSL_CIPHER = \'cipher_list\'\n | MASTER_SSL_VERIFY_SERVER_CERT = {0|1}\n | MASTER_USE_GTID = {current_pos|slave_pos|no}\n | MASTER_DEMOTE_TO_SLAVE = bool\n | IGNORE_SERVER_IDS = (server_id_list)\n | DO_DOMAIN_IDS = ([N,..])\n | IGNORE_DOMAIN_IDS = ([N,..])\n\nDescription\n-----------\n\nThe CHANGE MASTER statement sets the options that a replica uses to connect to\nand replicate from a primary.\n\nMariaDB starting with 10.7.0\n----------------------------\nThe FOR CHANNEL keyword was added for MySQL compatibility. This is identical\nto using the channel_name directly after CHANGE MASTER.\n\nMulti-Source Replication\n------------------------\n\nIf you are using multi-source replication, then you need to specify a\nconnection name when you execute CHANGE MASTER. There are two ways to do this:\n\n* Setting the default_master_connection system variable prior to executing\nCHANGE MASTER.\n* Setting the connection_name parameter when executing CHANGE MASTER.\n\ndefault_master_connection\n-------------------------\n\nSET default_master_connection = \'gandalf\';\nSTOP SLAVE;\nCHANGE MASTER TO \n MASTER_PASSWORD=\'new3cret\';\nSTART SLAVE;\n\nconnection_name\n---------------\n\nSTOP SLAVE \'gandalf\';\nCHANGE MASTER \'gandalf\' TO \n MASTER_PASSWORD=\'new3cret\';\nSTART SLAVE \'gandalf\';\n\nOptions\n-------\n\nConnection Options\n------------------\n\nMASTER_USER\n-----------\n\nThe MASTER_USER option for CHANGE MASTER defines the user account that the\nreplica will use to connect to the primary.\n\nThis user account will need the REPLICATION SLAVE privilege (or, from MariaDB\n10.5.1, the REPLICATION REPLICA on the primary.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_USER=\'repl\',\n MASTER_PASSWORD=\'new3cret\';\nSTART SLAVE;\n\nThe maximum length of the MASTER_USER string is 96 characters until MariaDB\n10.5, and 128 characters from MariaDB 10.6.\n\nMASTER_PASSWORD\n---------------\n\nThe MASTER_PASSWORD option for CHANGE MASTER defines the password that the\nreplica will use to connect to the primary as the user account defined by the\nMASTER_USER option.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO \n MASTER_PASSWORD=\'new3cret\';\nSTART SLAVE;\n\nThe maximum length of the MASTER_PASSWORD string is 32 characters. The\neffective maximum length of the string depends on how many bytes are used per\ncharacter and can be up to 96 characters.\n\nDue to MDEV-29994, the password can be silently truncated to 41 characters\nwhen MariaDB is restarted. For this reason it is recommended to use a password\nthat is shorter than this.\n\nMASTER_HOST\n-----------\n\nThe MASTER_HOST option for CHANGE MASTER defines the hostname or IP address of\nthe primary.\n\nIf you set the value of the MASTER_HOST option to the empty string, then that\nis not the same as not setting the option\'s value at all. If you set the value\nof the MASTER_HOST option to the empty string, then the CHANGE MASTER command\nwill fail with an error. In MariaDB 5.3 and before, if you set the value of\nthe MASTER_HOST option to the empty string, then the CHANGE MASTER command\nwould succeed, but the subsequent START SLAVE command would fail.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_HOST=\'dbserver1.example.com\',\n MASTER_USER=\'repl\',\n MASTER_PASSWORD=\'new3cret\',\n MASTER_USE_GTID=slave_pos;\nSTART SLAVE;\n\nIf you set the value of the MASTER_HOST option in a CHANGE MASTER command,\nthen the replica assumes that the primary is different from before, even if\nyou set the value of this option to the same value it had previously. In this\nscenario, the replica will consider the old values for the primary\'s binary\nlog file name and position to be invalid for the new primary. As a side\neffect, if you do not explicitly set the values of the MASTER_LOG_FILE and\nMASTER_LOG_POS options in the statement, then the statement will be implicitly\nappended with MASTER_LOG_FILE=\'\' and MASTER_LOG_POS=4. However, if you enable\nGTID mode for replication by setting the MASTER_USE_GTID option to some value\nother than no in the statement, then these values will effectively be ignored\nanyway.\n\nReplicas cannot connect to primaries using Unix socket files or Windows named\npipes. The replica must connect to the primary using TCP/IP.\n\nThe maximum length of the MASTER_HOST string is 60 characters until MariaDB\n10.5, and 255 characters from MariaDB 10.6.\n\nMASTER_PORT\n-----------\n\nThe MASTER_PORT option for CHANGE MASTER defines the TCP/IP port of the\nprimary.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_HOST=\'dbserver1.example.com\',\n MASTER_PORT=3307,\n MASTER_USER=\'repl\',\n MASTER_PASSWORD=\'new3cret\',\n MASTER_USE_GTID=slave_pos;\nSTART SLAVE;\n\nIf you set the value of the MASTER_PORT option in a CHANGE MASTER command,\nthen the replica assumes that the primary is different from before, even if\nyou set the value of this option to the same value it had previously. In this\nscenario, the replica will consider the old values for the primary\'s binary\nlog file name and position to be invalid for the new primary. As a side\neffect, if you do not explicitly set the values of the MASTER_LOG_FILE and\nMASTER_LOG_POS options in the statement, then the statement will be implicitly\nappended with MASTER_LOG_FILE=\'\' and MASTER_LOG_POS=4. However, if you enable\nGTID mode for replication by setting the MASTER_USE_GTID option to some value\nother than no in the statement, then these values will effectively be ignored\nanyway.\n\nReplicas cannot connect to primaries using Unix socket files or Windows named\npipes. The replica must connect to the primary using TCP/IP.\n\nMASTER_CONNECT_RETRY\n--------------------\n\nThe MASTER_CONNECT_RETRY option for CHANGE MASTER defines how many seconds\nthat the replica will wait between connection retries. The default is 60.\n\nSTOP SLAVE;\nCHANGE MASTER TO \n MASTER_CONNECT_RETRY=20;\nSTART SLAVE;\n\nThe number of connection attempts is limited by the master_retry_count option.\nIt can be set either on the command-line or in a server option group in an\noption file prior to starting up the server. For example:\n\n[mariadb]\n...\nmaster_retry_count=4294967295\n\nMASTER_BIND\n-----------\n\nThe MASTER_BIND option for CHANGE MASTER is only supported by MySQL 5.6.2 and\nlater and by MySQL NDB Cluster 7.3.1 and later. This option is not supported\nby MariaDB. See MDEV-19248 for more information.\n\nThe MASTER_BIND option for CHANGE MASTER can be used on replicas that have\nmultiple network interfaces to choose which network interface the replica will\nuse to connect to the primary.\n\nMASTER_HEARTBEAT_PERIOD\n-----------------------\n\nThe MASTER_HEARTBEAT_PERIOD option for CHANGE MASTER can be used to set the\ninterval in seconds between replication heartbeats. Whenever the primary\'s\nbinary log is updated with an event, the waiting period for the next heartbeat\nis reset.\n\nThis option\'s interval argument has the following characteristics:\n\n* It is a decimal value with a range of 0 to 4294967 seconds.\n* It has a resolution of hundredths of a second.\n* Its smallest valid non-zero value is 0.001.\n* Its default value is the value of the slave_net_timeout system variable\ndivided by 2.\n* If it\'s set to 0, then heartbeats are disabled.\n\nHeartbeats are sent by the primary only if there are no unsent events in the\nbinary log file for a period longer than the interval.\n\nIf the RESET SLAVE statement is executed, then the heartbeat interval is reset\nto the default.\n\nIf the slave_net_timeout system variable is set to a value that is lower than\nthe current heartbeat interval, then a warning will be issued.\n\nTLS Options\n-----------\n\nThe TLS options are used for providing information about TLS. The options can\nbe set even on replicas that are compiled without TLS support. The TLS options\nare saved to either the default master.info file or the file that is\nconfigured by the master_info_file option, but these TLS options are ignored\nunless the replica supports TLS.\n\nSee Replication with Secure Connections for more information.\n\nMASTER_SSL\n----------\n\nThe MASTER_SSL option for CHANGE MASTER tells the replica whether to force TLS\nfor the connection. The valid values are 0 or 1. Required to be set to 1 for\nthe other MASTER_SSL* options to have any effect.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_SSL=1;\nSTART SLAVE;\n\nMASTER_SSL_CA\n-------------\n\nThe MASTER_SSL_CA option for CHANGE MASTER defines a path to a PEM file that\nshould contain one or more X509 certificates for trusted Certificate\nAuthorities (CAs) to use for TLS. This option requires that you use the\nabsolute path, not a relative path.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_SSL_CERT=\'/etc/my.cnf.d/certificates/server-cert.pem\',\n MASTER_SSL_KEY=\'/etc/my.cnf.d/certificates/server-key.pem\',\n MASTER_SSL_CA=\'/etc/my.cnf.d/certificates/ca.pem\',\n MASTER_SSL_VERIFY_SERVER_CERT=1;\nSTART SLAVE;\n\nSee Secure Connections Overview: Certificate Authorities (CAs) for more\ninformation.\n\nThe maximum length of MASTER_SSL_CA string is 511 characters.\n\nMASTER_SSL_CAPATH\n-----------------\n\nThe MASTER_SSL_CAPATH option for CHANGE MASTER defines a path to a directory\nthat contains one or more PEM files that should each contain one X509\ncertificate for a trusted Certificate Authority (CA) to use for TLS. This\noption requires that you use the absolute path, not a relative path. The\ndirectory specified by this option needs to be run through the openssl rehash\ncommand.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_SSL_CERT=\'/etc/my.cnf.d/certificates/server-cert.pem\',\n MASTER_SSL_KEY=\'/etc/my.cnf.d/certificates/server-key.pem\',\n MASTER_SSL_CAPATH=\'/etc/my.cnf.d/certificates/ca/\',\n MASTER_SSL_VERIFY_SERVER_CERT=1;\nSTART SLAVE;\n\nSee Secure Connections Overview: Certificate Authorities (CAs) for more\ninformation.\n\nThe maximum length of MASTER_SSL_CA_PATH string is 511 characters.\n\nMASTER_SSL_CERT\n---------------\n\nThe MASTER_SSL_CERT option for CHANGE MASTER defines a path to the X509\ncertificate file to use for TLS. This option requires that you use the\nabsolute path, not a relative path.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_SSL_CERT=\'/etc/my.cnf.d/certificates/server-cert.pem\',\n MASTER_SSL_KEY=\'/etc/my.cnf.d/certificates/server-key.pem\',\n MASTER_SSL_CA=\'/etc/my.cnf.d/certificates/ca.pem\',\n MASTER_SSL_VERIFY_SERVER_CERT=1;\nSTART SLAVE;\n\nThe maximum length of MASTER_SSL_CERT string is 511 characters.\n\nMASTER_SSL_CRL\n--------------\n\nThe MASTER_SSL_CRL option for CHANGE MASTER defines a path to a PEM file that\nshould contain one or more revoked X509 certificates to use for TLS. This\noption requires that you use the absolute path, not a relative path.\n\nThis option is only supported if the server was built with OpenSSL. If the\nserver was built with yaSSL, then this option is not supported. See TLS and\nCryptography Libraries Used by MariaDB for more information about which\nlibraries are used on which platforms.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_SSL_CERT=\'/etc/my.cnf.d/certificates/server-cert.pem\',\n MASTER_SSL_KEY=\'/etc/my.cnf.d/certificates/server-key.pem\',\n MASTER_SSL_CA=\'/etc/my.cnf.d/certificates/ca.pem\',\n MASTER_SSL_VERIFY_SERVER_CERT=1,\n MASTER_SSL_CRL=\'/etc/my.cnf.d/certificates/crl.pem\';\nSTART SLAVE;\n\nSee Secure Connections Overview: Certificate Revocation Lists (CRLs) for more\ninformation.\n\nThe maximum length of MASTER_SSL_CRL string is 511 characters.\n\nMASTER_SSL_CRLPATH\n------------------\n\nThe MASTER_SSL_CRLPATH option for CHANGE MASTER defines a path to a directory\nthat contains one or more PEM files that should each contain one revoked X509\ncertificate to use for TLS. This option requires that you use the absolute\npath, not a relative path. The directory specified by this variable needs to\nbe run through the openssl rehash command.\n\nThis option is only supported if the server was built with OpenSSL. If the\nserver was built with yaSSL, then this option is not supported. See TLS and\nCryptography Libraries Used by MariaDB for more information about which\nlibraries are used on which platforms.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_SSL_CERT=\'/etc/my.cnf.d/certificates/server-cert.pem\',\n MASTER_SSL_KEY=\'/etc/my.cnf.d/certificates/server-key.pem\',\n MASTER_SSL_CA=\'/etc/my.cnf.d/certificates/ca.pem\',\n MASTER_SSL_VERIFY_SERVER_CERT=1,\n MASTER_SSL_CRLPATH=\'/etc/my.cnf.d/certificates/crl/\';\nSTART SLAVE;\n\nSee Secure Connections Overview: Certificate Revocation Lists (CRLs) for more\ninformation.\n\nThe maximum length of MASTER_SSL_CRL_PATH string is 511 characters.\n\nMASTER_SSL_KEY\n--------------\n\nThe MASTER_SSL_KEY option for CHANGE MASTER defines a path to a private key\nfile to use for TLS. This option requires that you use the absolute path, not\na relative path.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_SSL_CERT=\'/etc/my.cnf.d/certificates/server-cert.pem\',\n MASTER_SSL_KEY=\'/etc/my.cnf.d/certificates/server-key.pem\',\n MASTER_SSL_CA=\'/etc/my.cnf.d/certificates/ca.pem\',\n MASTER_SSL_VERIFY_SERVER_CERT=1;\nSTART SLAVE;\n\nThe maximum length of MASTER_SSL_KEY string is 511 characters.\n\nMASTER_SSL_CIPHER\n-----------------\n\nThe MASTER_SSL_CIPHER option for CHANGE MASTER defines the list of permitted\nciphers or cipher suites to use for TLS. Besides cipher names, if MariaDB was\ncompiled with OpenSSL, this option could be set to \"SSLv3\" or \"TLSv1.2\" to\nallow all SSLv3 or all TLSv1.2 ciphers. Note that the TLSv1.3 ciphers cannot\nbe excluded when using OpenSSL, even by using this option. See Using TLSv1.3\nfor details.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_SSL_CERT=\'/etc/my.cnf.d/certificates/server-cert.pem\',\n MASTER_SSL_KEY=\'/etc/my.cnf.d/certificates/server-key.pem\',\n MASTER_SSL_CA=\'/etc/my.cnf.d/certificates/ca.pem\',\n MASTER_SSL_VERIFY_SERVER_CERT=1,\n MASTER_SSL_CIPHER=\'TLSv1.2\';\nSTART SLAVE;\n\nThe maximum length of MASTER_SSL_CIPHER string is 511 characters.\n\nMASTER_SSL_VERIFY_SERVER_CERT\n-----------------------------\n\nThe MASTER_SSL_VERIFY_SERVER_CERT option for CHANGE MASTER enables server\ncertificate verification. This option is disabled by default.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_SSL_CERT=\'/etc/my.cnf.d/certificates/server-cert.pem\',\n MASTER_SSL_KEY=\'/etc/my.cnf.d/certificates/server-key.pem\',\n MASTER_SSL_CA=\'/etc/my.cnf.d/certificates/ca.pem\',\n MASTER_SSL_VERIFY_SERVER_CERT=1;\nSTART SLAVE;\n\nSee Secure Connections Overview: Server Certificate Verification for more\ninformation.\n\nBinary Log Options\n------------------\n\nThese options are related to the binary log position on the primary.\n\nMASTER_LOG_FILE\n---------------\n\nThe MASTER_LOG_FILE option for CHANGE MASTER can be used along with\nMASTER_LOG_POS to specify the coordinates at which the replica\'s I/O thread\nshould begin reading from the primary\'s binary logs the next time the thread\nstarts.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_LOG_FILE=\'master2-bin.001\',\n MASTER_LOG_POS=4;\nSTART SLAVE;\n\nThe MASTER_LOG_FILE and MASTER_LOG_POS options cannot be specified if the\nRELAY_LOG_FILE and RELAY_LOG_POS options were also specified.\n\nThe MASTER_LOG_FILE and MASTER_LOG_POS options are effectively ignored if you\nenable GTID mode for replication by setting the MASTER_USE_GTID option to some\nvalue other than no in the statement.\n\nMASTER_LOG_POS\n--------------\n\nThe MASTER_LOG_POS option for CHANGE MASTER can be used along with\nMASTER_LOG_FILE to specify the coordinates at which the replica\'s I/O thread\nshould begin reading from the primary\'s binary logs the next time the thread\nstarts.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_LOG_FILE=\'master2-bin.001\',\n MASTER_LOG_POS=4;\nSTART SLAVE;\n\nThe MASTER_LOG_FILE and MASTER_LOG_POS options cannot be specified if the\nRELAY_LOG_FILE and RELAY_LOG_POS options were also specified.\n\nThe MASTER_LOG_FILE and MASTER_LOG_POS options are effectively ignored if you\nenable GTID mode for replication by setting the MASTER_USE_GTID option to some\nvalue other than no in the statement.\n\nRelay Log Options\n-----------------\n\nThese options are related to the relay log position on the replica.\n\nRELAY_LOG_FILE\n--------------\n\nThe RELAY_LOG_FILE option for CHANGE MASTER can be used along with the\nRELAY_LOG_POS option to specify the coordinates at which the replica\'s SQL\nthread should begin reading from the relay log the next time the thread starts.\n\nThe CHANGE MASTER statement usually deletes all relay log files. However, if\nthe RELAY_LOG_FILE and/or RELAY_LOG_POS options are specified, then existing\nrelay log files are kept.\n\nWhen you want to change the relay log position, you only need to stop the\nreplica\'s SQL thread. The replica\'s I/O thread can continue running. The STOP\nSLAVE and START SLAVE statements support the SQL_THREAD option for this\nscenario. For example:\n\nSTOP SLAVE SQL_THREAD;\nCHANGE MASTER TO\n RELAY_LOG_FILE=\'slave-relay-bin.006\',\n RELAY_LOG_POS=4025;\nSTART SLAVE SQL_THREAD;\n\nWhen the value of this option is changed, the metadata about the replica\'s SQL\nthread\'s position in the relay logs will also be changed in the relay-log.info\nfile or the file that is configured by the relay_log_info_file system variable.\n\nThe RELAY_LOG_FILE and RELAY_LOG_POS options cannot be specified if the\nMASTER_LOG_FILE and MASTER_LOG_POS options were also specified.\n\nRELAY_LOG_POS\n-------------\n\nThe RELAY_LOG_POS option for CHANGE MASTER can be used along with the\nRELAY_LOG_FILE option to specify the coordinates at which the replica\'s SQL\nthread should begin reading from the relay log the next time the thread starts.\n\nThe CHANGE MASTER statement usually deletes all relay log files. However, if\nthe RELAY_LOG_FILE and/or RELAY_LOG_POS options are specified, then existing\nrelay log files are kept.\n\nWhen you want to change the relay log position, you only need to stop the\nreplica\'s SQL thread. The replica\'s I/O thread can continue running. The STOP\nSLAVE and START SLAVE statements support the SQL_THREAD option for this\nscenario. For example:\n\nSTOP SLAVE SQL_THREAD;\nCHANGE MASTER TO\n RELAY_LOG_FILE=\'slave-relay-bin.006\',\n RELAY_LOG_POS=4025;\nSTART SLAVE SQL_THREAD;\n\nWhen the value of this option is changed, the metadata about the replica\'s SQL\nthread\'s position in the relay logs will also be changed in the relay-log.info\nfile or the file that is configured by the relay_log_info_file system variable.\n\nThe RELAY_LOG_FILE and RELAY_LOG_POS options cannot be specified if the\nMASTER_LOG_FILE and MASTER_LOG_POS options were also specified.\n\nGTID Options\n------------\n\nMASTER_USE_GTID\n---------------\n\nThe MASTER_USE_GTID option for CHANGE MASTER can be used to configure the\nreplica to use the global transaction ID (GTID) when connecting to a primary.\nThe possible values are:\n\n* current_pos - Replicate in GTID mode and use gtid_current_pos as the\nposition to start downloading transactions from the primary. Deprecated from\nMariaDB 10.10. Using to transition to primary can break the replication state\nif the replica executes local transactions due to actively updating\ngtid_current_pos with gtid_binlog_pos and gtid_slave_pos. Use the new, safe,\nMASTER_DEMOTE_TO_SLAVE=<bool> option instead.\n* slave_pos - Replicate in GTID mode and use gtid_slave_pos as the position to\nstart downloading transactions from the primary. From MariaDB 10.5.1,\nreplica_pos is an alias for slave_pos.\n* no - Don\'t replicate in GTID mode.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_USE_GTID = current_pos;\nSTART SLAVE;\n\nOr:\n\nSTOP SLAVE;\nSET GLOBAL gtid_slave_pos=\'0-1-153\';\nCHANGE MASTER TO\n MASTER_USE_GTID = slave_pos;\nSTART SLAVE;\n\nMASTER_DEMOTE_TO_SLAVE\n----------------------\n\nMariaDB starting with 10.10\n---------------------------\nUsed to transition a primary to become a replica. Replaces the old\nMASTER_USE_GTID=current_pos with a safe alternative by forcing users to set\nUsing_Gtid=Slave_Pos and merging gtid_binlog_pos into gtid_slave_pos once at\nCHANGE MASTER TO time. If gtid_slave_pos is more recent than gtid_binlog_pos\n(as in the case of chain replication), the replication state should be\npreserved.\n\nFor example:\n\nSTOP SLAVE;\nCHANGE MASTER TO\n MASTER_DEMOTE_TO_SLAVE = 1;\nSTART SLAVE;\n\nReplication Filter Options\n--------------------------\n\nAlso see Replication filters.\n\nIGNORE_SERVER_IDS\n-----------------\n\nThe IGNORE_SERVER_IDS option for CHANGE MASTER can be used to configure a\nreplica to ignore binary log events that originated from certain servers.\nFiltered binary log events will not get logged to the replica’s relay log, and\nthey will not be applied by the replica.\n\nThe option\'s value can be specified by providing a comma-separated list of\nserver_id values. For example:\n\nSTOP SLAVE;\nCHANGE MASTER TO \n IGNORE_SERVER_IDS = (3,5);\nSTART SLAVE;\n\nIf you would like to clear a previously set list, then you can set the value\nto an empty list. For example:\n\nSTOP SLAVE;\nCHANGE MASTER TO \n IGNORE_SERVER_IDS = ();\nSTART SLAVE;\n\nDO_DOMAIN_IDS\n-------------\n\nThe DO_DOMAIN_IDS option for CHANGE MASTER can be used to configure a replica\nto only apply binary log events if the transaction\'s GTID is in a specific\ngtid_domain_id value. Filtered binary log events will not get logged to the\nreplica’s relay log, and they will not be applied by the replica.\n\nThe option\'s value can be specified by providing a comma-separated list of\ngtid_domain_id values. Duplicate values are automatically ignored. For example:\n\nSTOP SLAVE;\nCHANGE MASTER TO \n DO_DOMAIN_IDS = (1,2);\nSTART SLAVE;\n\nIf you would like to clear a previously set list, then you can set the value\nto an empty list. For example:\n\nSTOP SLAVE;\nCHANGE MASTER TO \n DO_DOMAIN_IDS = ();\nSTART SLAVE;\n\nThe DO_DOMAIN_IDS option and the IGNORE_DOMAIN_IDS option cannot both be set\nto non-empty values at the same time. If you want to set the DO_DOMAIN_IDS\noption, and the IGNORE_DOMAIN_IDS option was previously set, then you need to\nclear the value of the IGNORE_DOMAIN_IDS option. For example:\n\nSTOP SLAVE;\nCHANGE MASTER TO \n IGNORE_DOMAIN_IDS = (),\n DO_DOMAIN_IDS = (1,2);\nSTART SLAVE;\n\nThe DO_DOMAIN_IDS option can only be specified if the replica is replicating\nin GTID mode. Therefore, the MASTER_USE_GTID option must also be set to some\nvalue other than no in order to use this option.\n\nIGNORE_DOMAIN_IDS\n-----------------\n\nThe IGNORE_DOMAIN_IDS option for CHANGE MASTER can be used to configure a\nreplica to ignore binary log events if the transaction\'s GTID is in a specific\ngtid_domain_id value. Filtered binary log events will not get logged to the\nreplica’s relay log, and they will not be applied by the replica.\n\nThe option\'s value can be specified by providing a comma-separated list of\ngtid_domain_id values. Duplicate values are automatically ignored. For example:\n\nSTOP SLAVE;\nCHANGE MASTER TO \n IGNORE_DOMAIN_IDS = (1,2);\nSTART SLAVE;\n\nIf you would like to clear a previously set list, then you can set the value\nto an empty list. For example:\n\nSTOP SLAVE;\nCHANGE MASTER TO \n IGNORE_DOMAIN_IDS = ();\nSTART SLAVE;\n\nThe DO_DOMAIN_IDS option and the IGNORE_DOMAIN_IDS option cannot both be set\nto non-empty values at the same time. If you want to set the IGNORE_DOMAIN_IDS\noption, and the DO_DOMAIN_IDS option was previously set, then you need to\nclear the value of the DO_DOMAIN_IDS option. For example:\n\nSTOP SLAVE;\nCHANGE MASTER TO \n DO_DOMAIN_IDS = (),\n IGNORE_DOMAIN_IDS = (1,2);\nSTART SLAVE;\n\nThe IGNORE_DOMAIN_IDS option can only be specified if the replica is\nreplicating in GTID mode. Therefore, the MASTER_USE_GTID option must also be\nset to some value other than no in order to use this option.\n\nDelayed Replication Options\n---------------------------\n\nMASTER_DELAY\n------------\n\nThe MASTER_DELAY option for CHANGE MASTER can be used to enable delayed\nreplication. This option specifies the time in seconds (at least) that a\nreplica should lag behind the primary up to a maximum value of 2147483647, or\nabout 68 years. Before executing an event, the replica will first wait, if\nnecessary, until the given time has passed since the event was created on the\nprimary. The result is that the replica will reflect the state of the primary\nsome time back in the past. The default is zero, no delay.\n\nSTOP SLAVE;\nCHANGE MASTER TO \n MASTER_DELAY=3600;\nSTART SLAVE;\n\nChanging Option Values\n----------------------\n\nIf you don\'t specify a given option when executing the CHANGE MASTER\nstatement, then the option keeps its old value in most cases. Most of the\ntime, there is no need to specify the options that do not need to change. For\nexample, if the password for the user account that the replica uses to connect\nto its primary has changed, but no other options need to change, then you can\njust change the MASTER_PASSWORD option by executing the following commands:\n\nSTOP SLAVE;\nCHANGE MASTER TO \n MASTER_PASSWORD=\'new3cret\';\nSTART SLAVE;\n\nThere are some cases where options are implicitly reset, such as when the\nMASTER_HOST and MASTER_PORT options are changed.\n\nOption Persistence\n------------------\n\nThe values of the MASTER_LOG_FILE and MASTER_LOG_POS options (i.e. the binary\nlog position on the primary) and most other options are written to either the\ndefault master.info file or the file that is configured by the\nmaster_info_file option. The replica\'s I/O thread keeps this binary log\nposition updated as it downloads events only when MASTER_USE_GTID option is\nset to NO. Otherwise the file is not updated on a per event basis.\n\nThe master_info_file option can be set either on the command-line or in a\nserver option group in an option file prior to starting up the server. For\nexample:\n\n[mariadb]\n...\nmaster_info_file=/mariadb/myserver1-master.info\n\nThe values of the RELAY_LOG_FILE and RELAY_LOG_POS options (i.e. the relay log\nposition) are written to either the default relay-log.info file or the file\nthat is configured by the relay_log_info_file system variable. The replica\'s\nSQL thread keeps this relay log position updated as it applies events.\n\nThe relay_log_info_file system variable can be set either on the command-line\nor in a server option group in an option file prior to starting up the server.\nFor example:\n\n[mariadb]\n...\nrelay_log_info_file=/mariadb/myserver1-relay-log.info\n\nGTID Persistence\n----------------\n\nIf the replica is replicating binary log events that contain GTIDs, then the\nreplica\'s SQL thread will write every GTID that it applies to the\nmysql.gtid_slave_pos table. This GTID can be inspected and modified through\nthe gtid_slave_pos system variable.\n\nIf the replica has the log_slave_updates system variable enabled and if the\nreplica has the binary log enabled, then every write by the replica\'s SQL\nthread will also go into the replica\'s binary log. This means that GTIDs of\nreplicated transactions would be reflected in the value of the gtid_binlog_pos\nsystem variable.\n\nCreating a Replica from a Backup\n--------------------------------\n\nThe CHANGE MASTER statement is useful for setting up a replica when you have a\nbackup of the primary and you also have the binary log position or GTID\nposition corresponding to the backup.\n\nAfter restoring the backup on the replica, you could execute something like\nthis to use the binary log position:\n\nCHANGE MASTER TO\n MASTER_LOG_FILE=\'master2-bin.001\',\n MASTER_LOG_POS=4;\nSTART SLAVE;\n\nOr you could execute something like this to use the GTID position:\n\nSET GLOBAL gtid_slave_pos=\'0-1-153\';\nCHANGE MASTER TO\n MASTER_USE_GTID=slave_pos;\nSTART SLAVE;\n\nSee Setting up a Replication Slave with Mariabackup for more information on\nhow to do this with Mariabackup.\n\nExample\n-------\n\nThe following example changes the primary and primary\'s binary log\ncoordinates. This is used when you want to set up the replica to replicate the\nprimary:\n\nCHANGE MASTER TO\n MASTER_HOST=\'master2.mycompany.com\',\n MASTER_USER=\'replication\',\n MASTER_PASSWORD=\'bigs3cret\',\n MASTER_PORT=3306,\n MASTER_LOG_FILE=\'master2-bin.001\',\n MASTER_LOG_POS=4,\n MASTER_CONNECT_RETRY=10;\nSTART SLAVE;\n\nURL: https://mariadb.com/kb/en/change-master-to/','','https://mariadb.com/kb/en/change-master-to/'),
(829,'RESET MASTER',49,'RESET MASTER [TO #]\n\nDeletes all binary log files listed in the index file, resets the binary log\nindex file to be empty, and creates a new binary log file with a suffix of\n.000001.\n\nIf TO # is given, then the first new binary log file will start from number #.\n\nThis statement is for use only when the master is started for the first time,\nand should never be used if any slaves are actively replicating from the\nbinary log.\n\nURL: https://mariadb.com/kb/en/reset-master/','','https://mariadb.com/kb/en/reset-master/'),
(316,'Cursor Overview',24,'Description\n-----------\n\nA cursor is a structure that allows you to go over records sequentially, and\nperform processing based on the result.\n\nMariaDB permits cursors inside stored programs, and MariaDB cursors are\nnon-scrollable, read-only and asensitive.\n\n* Non-scrollable means that the rows can only be fetched in the order\nspecified by the SELECT statement. Rows cannot be skipped, you cannot jump to\na specific row, and you cannot fetch rows in reverse order.\n* Read-only means that data cannot be updated through the cursor.\n* Asensitive means that the cursor points to the actual underlying data. This\nkind of cursor is quicker than the alternative, an insensitive cursor, as no\ndata is copied to a temporary table. However, changes to the data being used\nby the cursor will affect the cursor data.\n\nCursors are created with a DECLARE CURSOR statement and opened with an OPEN\nstatement. Rows are read with a FETCH statement before the cursor is finally\nclosed with a CLOSE statement.\n\nWhen FETCH is issued and there are no more rows to extract, the following\nerror is produced:\n\nERROR 1329 (02000): No data - zero rows fetched, selected, or processed\n\nTo avoid problems, a DECLARE HANDLER statement is generally used. The HANDLER\nshould handler the 1329 error, or the \'02000\' SQLSTATE, or the NOT FOUND error\nclass.\n\nOnly SELECT statements are allowed for cursors, and they cannot be contained\nin a variable - so, they cannot be composed dynamically. However, it is\npossible to SELECT from a view. Since the CREATE VIEW statement can be\nexecuted as a prepared statement, it is possible to dynamically create the\nview that is queried by the cursor.\n\nFrom MariaDB 10.3.0, cursors can have parameters. Cursor parameters can appear\nin any part of the DECLARE CURSOR select_statement where a stored procedure\nvariable is allowed (select list, WHERE, HAVING, LIMIT etc). See DECLARE\nCURSOR and OPEN for syntax, and below for an example:\n\nExamples\n--------\n\nCREATE TABLE c1(i INT);\n\nCREATE TABLE c2(i INT);\n\nCREATE TABLE c3(i INT);\n\nDELIMITER //\n\nCREATE PROCEDURE p1()\nBEGIN\n DECLARE done INT DEFAULT FALSE;\n DECLARE x, y INT;\n DECLARE cur1 CURSOR FOR SELECT i FROM test.c1;\n DECLARE cur2 CURSOR FOR SELECT i FROM test.c2;\n DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;\n\nOPEN cur1;\n OPEN cur2;\n\nread_loop: LOOP\n  FETCH cur1 INTO x;\n  FETCH cur2 INTO y;\n  IF done THEN\n   LEAVE read_loop;\n  END IF;\n  IF x < y THEN\n   INSERT INTO test.c3 VALUES (x);\n  ELSE\n   INSERT INTO test.c3 VALUES (y);\n  END IF;\n END LOOP;\n\nCLOSE cur1;\n CLOSE cur2;\nEND; //\n\nDELIMITER ;\n\nINSERT INTO c1 VALUES(5),(50),(500);\n\nINSERT INTO c2 VALUES(10),(20),(30);\n\nCALL p1;\n\nSELECT * FROM c3;\n+------+\n| i    |\n+------+\n|    5 |\n|   20 |\n|   30 |\n+------+\n\nFrom MariaDB 10.3.0\n\nDROP PROCEDURE IF EXISTS p1;\nDROP TABLE IF EXISTS t1;\nCREATE TABLE t1 (a INT, b VARCHAR(10));\n\nINSERT INTO t1 VALUES (1,\'old\'),(2,\'old\'),(3,\'old\'),(4,\'old\'),(5,\'old\');\n\nDELIMITER //\n\nCREATE PROCEDURE p1(min INT,max INT)\nBEGIN\n DECLARE done INT DEFAULT FALSE;\n DECLARE va INT;\n DECLARE cur CURSOR(pmin INT, pmax INT) FOR SELECT a FROM t1 WHERE a BETWEEN\npmin AND pmax;\n DECLARE CONTINUE HANDLER FOR NOT FOUND SET done=TRUE;\n OPEN cur(min,max);\n read_loop: LOOP\n  FETCH cur INTO va;\n  IF done THEN\n   LEAVE read_loop;\n  END IF;\n  INSERT INTO t1 VALUES (va,\'new\');\n END LOOP;\n CLOSE cur;\nEND;\n//\n\nDELIMITER ;\n\nCALL p1(2,4);\n\nSELECT * FROM t1;\n+------+------+\n| a    | b    |\n+------+------+\n|    1 | old  |\n|    2 | old  |\n|    3 | old  |\n|    4 | old  |\n|    5 | old  |\n|    2 | new  |\n|    3 | new  |\n|    4 | new  |\n+------+------+\n\nURL: https://mariadb.com/kb/en/cursor-overview/','','https://mariadb.com/kb/en/cursor-overview/'),
(327,'MULTIPOLYGON',25,'Syntax\n------\n\nMultiPolygon(poly1,poly2,...)\n\nDescription\n-----------\n\nConstructs a WKB MultiPolygon value from a set of WKB Polygon arguments. If\nany argument is not a WKB Polygon, the return value is NULL.\n\nExample\n-------\n\nCREATE TABLE gis_multi_polygon  (g MULTIPOLYGON);\nINSERT INTO gis_multi_polygon VALUES\n  (MultiPolygonFromText(\'MULTIPOLYGON(((28 26,28 0,84 0,84 42,28 26),(52\n18,66 23,73 9,48 6,52 18)),\n  ((59 18,67 18,67 13,59 13,59 18)))\')),\n  (MPolyFromText(\'MULTIPOLYGON(((28 26,28 0,84 0,84 42,28 26),(52 18,66\n23,73 9,48 6,52 18)),\n    ((59 18,67 18,67 13,59 13,59 18)))\')),\n  (MPolyFromWKB(AsWKB(MultiPolygon(Polygon(LineString(\n   Point(0, 3), Point(3, 3), Point(3, 0), Point(0, 3)))))));\n\nURL: https://mariadb.com/kb/en/multipolygon/','','https://mariadb.com/kb/en/multipolygon/'),
(330,'POLYGON',25,'Syntax\n------\n\nPolygon(ls1,ls2,...)\n\nDescription\n-----------\n\nConstructs a WKB Polygon value from a number of WKB LineString arguments. If\nany argument does not represent the WKB of a LinearRing (that is, not a closed\nand simple LineString) the return value is NULL.\n\nNote that according to the OpenGIS standard, a POLYGON should have exactly one\nExteriorRing and all other rings should lie within that ExteriorRing and thus\nbe the InteriorRings. Practically, however, some systems, including MariaDB\'s,\npermit polygons to have several \'ExteriorRings\'. In the case of there being\nmultiple, non-overlapping exterior rings ST_NUMINTERIORRINGS() will return 1.\n\nExamples\n--------\n\nSET @g = ST_GEOMFROMTEXT(\'POLYGON((1 1,1 5,4 9,6 9,9 3,7 2,1 1))\');\n\nCREATE TABLE gis_polygon   (g POLYGON);\nINSERT INTO gis_polygon VALUES\n  (PolygonFromText(\'POLYGON((10 10,20 10,20 20,10 20,10 10))\')),\n  (PolyFromText(\'POLYGON((0 0,50 0,50 50,0 50,0 0), (10 10,20 10,20 20,10\n20,10 10))\')),\n  (PolyFromWKB(AsWKB(Polygon(LineString(Point(0, 0), Point(30, 0), Point(30,\n30), Point(0, 0))))));\n\nNon-overlapping \'polygon\':\n\nSELECT ST_NumInteriorRings(ST_PolyFromText(\'POLYGON((0 0,10 0,10 10,0 10,0 0),\n (-1 -1,-5 -1,-5 -5,-1 -5,-1 -1))\')) AS NumInteriorRings;\n+------------------+\n| NumInteriorRings |\n+------------------+\n|                1 |\n+------------------+\n\nURL: https://mariadb.com/kb/en/polygon/','','https://mariadb.com/kb/en/polygon/'),
(331,'ST_BUFFER',25,'Syntax\n------\n\nST_BUFFER(g1,r)\nBUFFER(g1,r)\n\nDescription\n-----------\n\nReturns a geometry that represents all points whose distance from geometry g1\nis less than or equal to distance, or radius, r.\n\nUses for this function could include creating for example a new geometry\nrepresenting a buffer zone around an island.\n\nBUFFER() is a synonym.\n\nExamples\n--------\n\nDetermining whether a point is within a buffer zone:\n\nSET @g1 = ST_GEOMFROMTEXT(\'POLYGON((10 10, 10 20, 20 20, 20 10, 10 10))\');\n\nSET @g2 = ST_GEOMFROMTEXT(\'POINT(8 8)\');\n\nSELECT ST_WITHIN(@g2,ST_BUFFER(@g1,5));\n+---------------------------------+\n| ST_WITHIN(@g2,ST_BUFFER(@g1,5)) |\n+---------------------------------+\n|                               1 |\n+---------------------------------+\n\nSELECT ST_WITHIN(@g2,ST_BUFFER(@g1,1));\n+---------------------------------+\n| ST_WITHIN(@g2,ST_BUFFER(@g1,1)) |\n+---------------------------------+\n|                               0 |\n+---------------------------------+\n\nURL: https://mariadb.com/kb/en/st_buffer/','','https://mariadb.com/kb/en/st_buffer/'),
(332,'ST_CONVEXHULL',25,'MariaDB starting with 10.1.2\n----------------------------\nST_ConvexHull() was introduced in MariaDB 10.1.2\n\nSyntax\n------\n\nST_ConvexHull(g)\nConvexHull(g)\n\nDescription\n-----------\n\nGiven a geometry, returns a geometry that is the minimum convex geometry\nenclosing all geometries within the set. Returns NULL if the geometry value is\nNULL or an empty value.\n\nST_ConvexHull() and ConvexHull() are synonyms.\n\nExamples\n--------\n\nThe ConvexHull of a single point is simply the single point:\n\nSET @g = ST_GEOMFROMTEXT(\'Point(0 0)\');\n\nSELECT ST_ASTEXT(ST_CONVEXHULL(@g));\n+------------------------------+\n| ST_ASTEXT(ST_CONVEXHULL(@g)) |\n+------------------------------+\n| POINT(0 0)                   |\n+------------------------------+\n\nSET @g = ST_GEOMFROMTEXT(\'MultiPoint(0 0, 1 2, 2 3)\');\n\nSELECT ST_ASTEXT(ST_CONVEXHULL(@g));\n+------------------------------+\n| ST_ASTEXT(ST_CONVEXHULL(@g)) |\n+------------------------------+\n| POLYGON((0 0,1 2,2 3,0 0))   |\n+------------------------------+\n\nSET @g = ST_GEOMFROMTEXT(\'MultiPoint( 1 1, 2 2, 5 3, 7 2, 9 3, 8 4, 6 6, 6 9,\n4 9, 1 5 )\');\n\nSELECT ST_ASTEXT(ST_CONVEXHULL(@g));\n+----------------------------------------+\n| ST_ASTEXT(ST_CONVEXHULL(@g))           |\n+----------------------------------------+\n| POLYGON((1 1,1 5,4 9,6 9,9 3,7 2,1 1)) |\n+----------------------------------------+\n\nURL: https://mariadb.com/kb/en/st_convexhull/','','https://mariadb.com/kb/en/st_convexhull/'),
(335,'ST_SYMDIFFERENCE',25,'Syntax\n------\n\nST_SYMDIFFERENCE(g1,g2)\n\nDescription\n-----------\n\nReturns a geometry that represents the portions of geometry g1 and geometry g2\nthat don\'t intersect.\n\nExamples\n--------\n\nSET @g1 = ST_GEOMFROMTEXT(\'LINESTRING(10 20, 10 40)\');\n\nSET @g2 = ST_GEOMFROMTEXT(\'LINESTRING(10 15, 10 25)\');\n\nSELECT ASTEXT(ST_SYMDIFFERENCE(@g1,@g2));\n+----------------------------------------------+\n| ASTEXT(ST_SYMDIFFERENCE(@g1,@g2))            |\n+----------------------------------------------+\n| MULTILINESTRING((10 15,10 20),(10 25,10 40)) |\n+----------------------------------------------+\n\nSET @g2 = ST_GeomFromText(\'LINESTRING(10 20, 10 41)\');\n\nSELECT ASTEXT(ST_SYMDIFFERENCE(@g1,@g2));\n+-----------------------------------+\n| ASTEXT(ST_SYMDIFFERENCE(@g1,@g2)) |\n+-----------------------------------+\n| LINESTRING(10 40,10 41)           |\n+-----------------------------------+\n\nURL: https://mariadb.com/kb/en/st_symdifference/','','https://mariadb.com/kb/en/st_symdifference/'),
(336,'ST_UNION',25,'Syntax\n------\n\nST_UNION(g1,g2)\n\nDescription\n-----------\n\nReturns a geometry that is the union of the geometry g1 and geometry g2.\n\nExamples\n--------\n\nSET @g1 = GEOMFROMTEXT(\'POINT (0 2)\');\n\nSET @g2 = GEOMFROMTEXT(\'POINT (2 0)\');\n\nSELECT ASTEXT(ST_UNION(@g1,@g2));\n+---------------------------+\n| ASTEXT(ST_UNION(@g1,@g2)) |\n+---------------------------+\n| MULTIPOINT(2 0,0 2)       |\n+---------------------------+\n\nSET @g1 = GEOMFROMTEXT(\'POLYGON((0 0,0 3,3 3,3 0,0 0))\');\n\nSET @g2 = GEOMFROMTEXT(\'POLYGON((2 2,4 2,4 4,2 4,2 2))\');\n\nSELECT ASTEXT(ST_UNION(@g1,@g2));\n+------------------------------------------------+\n| ASTEXT(ST_UNION(@g1,@g2))                      |\n+------------------------------------------------+\n| POLYGON((0 0,0 3,2 3,2 4,4 4,4 2,3 2,3 0,0 0)) |\n+------------------------------------------------+\n\nURL: https://mariadb.com/kb/en/st_union/','','https://mariadb.com/kb/en/st_union/'),
(337,'SHOW GRANTS',26,'Syntax\n------\n\nSHOW GRANTS [FOR user|role]\n\nDescription\n-----------\n\nThe SHOW GRANTS statement lists privileges granted to a particular user or\nrole.\n\nUsers\n-----\n\nThe statement lists the GRANT statement or statements that must be issued to\nduplicate the privileges that are granted to a MariaDB user account. The\naccount is named using the same format as for the GRANT statement; for\nexample, \'jeffrey\'@\'localhost\'. If you specify only the user name part of the\naccount name, a host name part of \'%\' is used. For additional information\nabout specifying account names, see GRANT.\n\nSHOW GRANTS FOR \'root\'@\'localhost\';\n+---------------------------------------------------------------------+\n| Grants for root@localhost                                           |\n+---------------------------------------------------------------------+\n| GRANT ALL PRIVILEGES ON *.* TO \'root\'@\'localhost\' WITH GRANT OPTION |\n+---------------------------------------------------------------------+\n\nTo list the privileges granted to the account that you are using to connect to\nthe server, you can use any of the following statements:\n\nSHOW GRANTS;\nSHOW GRANTS FOR CURRENT_USER;\nSHOW GRANTS FOR CURRENT_USER();\n\nIf SHOW GRANTS FOR CURRENT_USER (or any of the equivalent syntaxes) is used in\nDEFINER context (such as within a stored procedure that is defined with SQL\nSECURITY DEFINER), the grants displayed are those of the definer and not the\ninvoker.\n\nNote that the DELETE HISTORY privilege, introduced in MariaDB 10.3.4, was\ndisplayed as DELETE VERSIONING ROWS when running SHOW GRANTS until MariaDB\n10.3.15 (MDEV-17655).\n\nRoles\n-----\n\nSHOW GRANTS can also be used to view the privileges granted to a role.\n\nExample\n-------\n\nSHOW GRANTS FOR journalist;\n+------------------------------------------+\n| Grants for journalist                    |\n+------------------------------------------+\n| GRANT USAGE ON *.* TO \'journalist\'       |\n| GRANT DELETE ON `test`.* TO \'journalist\' |\n+------------------------------------------+\n\nFOR PUBLIC\n----------\n\nMariaDB starting with 10.11\n---------------------------\nGRANT ... TO PUBLIC was introduced in MariaDB 10.11 to grant privileges to all\nusers. SHOW GRANTS FOR PUBLIC shows all these grants.\n\nSHOW GRANTS FOR public;\n+------------------------------------------------+\n| Grants for PUBLIC                              |\n+------------------------------------------------+\n| GRANT ALL PRIVILEGES ON `dev_db`.* TO `PUBLIC` |\n+------------------------------------------------+\n\nURL: https://mariadb.com/kb/en/show-grants/','','https://mariadb.com/kb/en/show-grants/'),
(338,'SHOW CREATE USER',26,'Syntax\n------\n\nSHOW CREATE USER user_name\n\nDescription\n-----------\n\nShows the CREATE USER statement that created the given user. The statement\nrequires the SELECT privilege for the mysql database, except for the current\nuser.\n\nExamples\n--------\n\nCREATE USER foo4@test require cipher \'text\' \n issuer \'foo_issuer\' subject \'foo_subject\';\n\nSHOW CREATE USER foo4@test\\G\n*************************** 1. row ***************************\nCREATE USER \'foo4\'@\'test\' \n REQUIRE ISSUER \'foo_issuer\'\n SUBJECT \'foo_subject\'\n CIPHER \'text\'\n\nUser Password Expiry:\n\nCREATE USER \'monty\'@\'localhost\' PASSWORD EXPIRE INTERVAL 120 DAY;\n\nSHOW CREATE USER \'monty\'@\'localhost\';\n+------------------------------------------------------------------+\n| CREATE USER for monty@localhost                                  |\n+------------------------------------------------------------------+\n| CREATE USER \'monty\'@\'localhost\' PASSWORD EXPIRE INTERVAL 120 DAY |\n+------------------------------------------------------------------+\n\nURL: https://mariadb.com/kb/en/show-create-user/','','https://mariadb.com/kb/en/show-create-user/'),
(340,'SHOW CREATE TABLE',26,'Syntax\n------\n\nSHOW CREATE TABLE tbl_name\n\nDescription\n-----------\n\nShows the CREATE TABLE statement that created the given table. The statement\nrequires the SELECT privilege for the table. This statement also works with\nviews and SEQUENCE.\n\nSHOW CREATE TABLE quotes table and column names according to the value of the\nsql_quote_show_create server system variable.\n\nCertain SQL_MODE values can result in parts of the original CREATE statement\nnot being included in the output. MariaDB-specific table options, column\noptions, and index options are not included in the output of this statement if\nthe NO_TABLE_OPTIONS, NO_FIELD_OPTIONS and NO_KEY_OPTIONS SQL_MODE flags are\nused. All MariaDB-specific table attributes are also not shown when a\nnon-MariaDB/MySQL emulation mode is used, which includes ANSI, DB2,\nPOSTGRESQL, MSSQL, MAXDB or ORACLE.\n\nInvalid table options, column options and index options are normally commented\nout (note, that it is possible to create a table with invalid options, by\naltering a table of a different engine, where these options were valid). To\nhave them uncommented, enable the IGNORE_BAD_TABLE_OPTIONS SQL_MODE. Remember\nthat replaying a CREATE TABLE statement with uncommented invalid options will\nfail with an error, unless the IGNORE_BAD_TABLE_OPTIONS SQL_MODE is in effect.\n\nNote that SHOW CREATE TABLE is not meant to provide metadata about a table. It\nprovides information about how the table was declared, but the real table\nstructure could differ a bit. For example, if an index has been declared as\nHASH, the CREATE TABLE statement returned by SHOW CREATE TABLE will declare\nthat index as HASH; however, it is possible that the index is in fact a BTREE,\nbecause the storage engine does not support HASH.\n\nMariaDB starting with 10.2.1\n----------------------------\nMariaDB 10.2.1 permits TEXT and BLOB data types to be assigned a DEFAULT\nvalue. As a result, from MariaDB 10.2.1, SHOW CREATE TABLE will append a\nDEFAULT NULL to nullable TEXT or BLOB fields if no specific default is\nprovided.\n\nMariaDB starting with 10.2.2\n----------------------------\nFrom MariaDB 10.2.2, numbers are no longer quoted in the DEFAULT clause in\nSHOW CREATE statement. Previously, MariaDB quoted numbers.\n\nIndex Order\n-----------\n\nIndexes are sorted and displayed in the following order, which may differ from\nthe order of the CREATE TABLE statement.\n\n* PRIMARY KEY\n* UNIQUE keys where all column are NOT NULL\n* UNIQUE keys that don\'t contain partial segments\n* Other UNIQUE keys\n* LONG UNIQUE keys\n* Normal keys\n* Fulltext keys\n\nSee sql/sql_table.cc for details.\n\nExamples\n--------\n\nSHOW CREATE TABLE t\\G\n*************************** 1. row ***************************\n   Table: t\nCreate Table: CREATE TABLE `t` (\n `id` int(11) NOT NULL AUTO_INCREMENT,\n `s` char(60) DEFAULT NULL,\n PRIMARY KEY (`id`)\n) ENGINE=InnoDB DEFAULT CHARSET=latin1\n\nWith sql_quote_show_create off:\n\nSHOW CREATE TABLE t\\G\n*************************** 1. row ***************************\n   Table: t\nCreate Table: CREATE TABLE t (\n id int(11) NOT NULL AUTO_INCREMENT,\n s char(60) DEFAULT NULL,\n PRIMARY KEY (id)\n) ENGINE=InnoDB DEFAULT CHARSET=latin1\n\nUnquoted numeric DEFAULTs, from MariaDB 10.2.2:\n\nCREATE TABLE td (link TINYINT DEFAULT 1);\n\nSHOW CREATE TABLE td\\G\n*************************** 1. row ***************************\n   Table: td\nCreate Table: CREATE TABLE `td` (\n `link` tinyint(4) DEFAULT 1\n) ENGINE=InnoDB DEFAULT CHARSET=latin1\n\nQuoted numeric DEFAULTs, until MariaDB 10.2.1:\n\nCREATE TABLE td (link TINYINT DEFAULT 1);\n\nSHOW CREATE TABLE td\\G\n*************************** 1. row ***************************\n   Table: td\nCreate Table: CREATE TABLE `td` (\n `link` tinyint(4) DEFAULT \'1\'\n) ENGINE=InnoDB DEFAULT CHARSET=latin1\n\nSQL_MODE impacting the output:\n\nSELECT @@sql_mode;\n+------------------------------------------------------------------------------\n------------+\n| @@sql_mode                                                                  \n      |\n+------------------------------------------------------------------------------\n------------+\n|\nSTRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SU\nSTITUTION |\n+------------------------------------------------------------------------------\n------------+\n\nCREATE TABLE `t1` (\n   `id` int(11) NOT NULL AUTO_INCREMENT,\n   `msg` varchar(100) DEFAULT NULL,\n   PRIMARY KEY (`id`)\n  ) ENGINE=InnoDB DEFAULT CHARSET=latin1\n;\n\nSHOW CREATE TABLE t1\\G\n*************************** 1. row ***************************\n   Table: t1\nCreate Table: CREATE TABLE `t1` (\n `id` int(11) NOT NULL AUTO_INCREMENT,\n `msg` varchar(100) DEFAULT NULL,\n PRIMARY KEY (`id`)\n) ENGINE=InnoDB DEFAULT CHARSET=latin1\n\nSET SQL_MODE=ORACLE;\n\nSHOW CREATE TABLE t1\\G\n*************************** 1. row ***************************\n   Table: t1\nCreate Table: CREATE TABLE \"t1\" (\n \"id\" int(11) NOT NULL,\n \"msg\" varchar(100) DEFAULT NULL,\n PRIMARY KEY (\"id\")\n\nURL: https://mariadb.com/kb/en/show-create-table/','','https://mariadb.com/kb/en/show-create-table/'),
(339,'SHOW COLUMNS',26,'Syntax\n------\n\nSHOW [FULL] {COLUMNS | FIELDS} FROM tbl_name [FROM db_name]\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nSHOW COLUMNS displays information about the columns in a given table. It also\nworks for views. The LIKE clause, if present on its own, indicates which\ncolumn names to match. The WHERE and LIKE clauses can be given to select rows\nusing more general conditions, as discussed in Extended SHOW.\n\nIf the data types differ from what you expect them to be based on a CREATE\nTABLE statement, note that MariaDB sometimes changes data types when you\ncreate or alter a table. The conditions under which this occurs are described\nin the Silent Column Changes article.\n\nThe FULL keyword causes the output to include the column collation and\ncomments, as well as the privileges you have for each column.\n\nYou can use db_name.tbl_name as an alternative to the tbl_name FROM db_name\nsyntax. In other words, these two statements are equivalent:\n\nSHOW COLUMNS FROM mytable FROM mydb;\nSHOW COLUMNS FROM mydb.mytable;\n\nSHOW COLUMNS displays the following values for each table column:\n\nField indicates the column name.\n\nType indicates the column data type.\n\nCollation indicates the collation for non-binary string columns, or NULL for\nother columns. This value is displayed only if you use the FULL keyword.\n\nThe Null field contains YES if NULL values can be stored in the column, NO if\nnot.\n\nThe Key field indicates whether the column is indexed:\n\n* If Key is empty, the column either is not indexed or is indexed only as a\n secondary column in a multiple-column, non-unique index.\n* If Key is PRI, the column is a PRIMARY KEY or\n is one of the columns in a multiple-column PRIMARY KEY.\n* If Key is UNI, the column is the first column of a unique-valued\n index that cannot contain NULL values.\n* If Key is MUL, multiple occurrences of a given value are allowed\n within the column. The column is the first column of a non-unique index or a\n unique-valued index that can contain NULL values.\n\nIf more than one of the Key values applies to a given column of a table, Key\ndisplays the one with the highest priority, in the order PRI, UNI, MUL.\n\nA UNIQUE index may be displayed as PRI if it cannot contain NULL values and\nthere is no PRIMARY KEY in the table. A UNIQUE index may display as MUL if\nseveral columns form a composite UNIQUE index; although the combination of the\ncolumns is unique, each column can still hold multiple occurrences of a given\nvalue.\n\nThe Default field indicates the default value that is assigned to the column.\n\nThe Extra field contains any additional information that is available about a\ngiven column.\n\n+------------------------+---------------------------------------------------+\n| Value                  | Description                                       |\n+------------------------+---------------------------------------------------+\n| AUTO_INCREMENT         | The column was created with the AUTO_INCREMENT    |\n|                        | keyword.                                          |\n+------------------------+---------------------------------------------------+\n| PERSISTENT             | The column was created with the PERSISTENT        |\n|                        | keyword. (New in 5.3)                             |\n+------------------------+---------------------------------------------------+\n| VIRTUAL                | The column was created with the VIRTUAL keyword.  |\n|                        | (New in 5.3)                                      |\n+------------------------+---------------------------------------------------+\n| on update              | The column is a TIMESTAMP column that is          |\n| CURRENT_TIMESTAMP      | automatically updated on INSERT and UPDATE.       |\n+------------------------+---------------------------------------------------+\n\nPrivileges indicates the privileges you have for the column. This value is\ndisplayed only if you use the FULL keyword.\n\nComment indicates any comment the column has. This value is displayed only if\nyou use the FULL keyword.\n\nSHOW FIELDS is a synonym for SHOW COLUMNS. Also DESCRIBE and EXPLAIN can be\nused as shortcuts.\n\nYou can also list a table\'s columns with:\n\nmariadb-show db_name tbl_name\n\nSee the mariadb-show command for more details.\n\nThe DESCRIBE statement provides information similar to SHOW COLUMNS. The\ninformation_schema.COLUMNS table provides similar, but more complete,\ninformation.\n\nThe SHOW CREATE TABLE, SHOW TABLE STATUS, and SHOW INDEX statements also\nprovide information about tables.\n\nExamples\n--------\n\nSHOW COLUMNS FROM city;\n+------------+----------+------+-----+---------+----------------+\n| Field      | Type     | Null | Key | Default | Extra          |\n+------------+----------+------+-----+---------+----------------+\n| Id         | int(11)  | NO   | PRI | NULL    | auto_increment |\n| Name       | char(35) | NO   |     |         |                |\n| Country    | char(3)  | NO   | UNI |         |                |\n| District   | char(20) | YES  | MUL |         |                |\n| Population | int(11)  | NO   |     | 0       |                |\n+------------+----------+------+-----+---------+----------------+\n\nSHOW COLUMNS FROM employees WHERE Type LIKE \'Varchar%\';\n+---------------+-------------+------+-----+---------+-------+\n| Field         | Type        | Null | Key | Default | Extra |\n+---------------+-------------+------+-----+---------+-------+\n| first_name    | varchar(30) | NO   | MUL | NULL    |       |\n| last_name     | varchar(40) | NO   |     | NULL    |       |\n| position      | varchar(25) | NO   |     | NULL    |       |\n| home_address  | varchar(50) | NO   |     | NULL    |       |\n| home_phone    | varchar(12) | NO   |     | NULL    |       |\n| employee_code | varchar(25) | NO   | UNI | NULL    |       |\n+---------------+-------------+------+-----+---------+-------+\n\nURL: https://mariadb.com/kb/en/show-columns/','','https://mariadb.com/kb/en/show-columns/'),
(341,'SHOW INDEX',26,'Syntax\n------\n\nSHOW {INDEX | INDEXES | KEYS} \n FROM tbl_name [FROM db_name]\n [WHERE expr]\n\nDescription\n-----------\n\nSHOW INDEX returns table index information. The format resembles that of the\nSQLStatistics call in ODBC.\n\nYou can use db_name.tbl_name as an alternative to the tbl_name FROM db_name\nsyntax. These two statements are equivalent:\n\nSHOW INDEX FROM mytable FROM mydb;\nSHOW INDEX FROM mydb.mytable;\n\nSHOW KEYS and SHOW INDEXES are synonyms for SHOW INDEX.\n\nYou can also list a table\'s indexes with the mariadb-show command:\n\nmariadb-show -k db_name tbl_name\n\nThe information_schema.STATISTICS table stores similar information.\n\nThe following fields are returned by SHOW INDEX.\n\n+------------------------+---------------------------------------------------+\n| Field                  | Description                                       |\n+------------------------+---------------------------------------------------+\n| Table                  | Table name                                        |\n+------------------------+---------------------------------------------------+\n| Non_unique             | 1 if the index permits duplicate values, 0 if     |\n|                        | values must be unique.                            |\n+------------------------+---------------------------------------------------+\n| Key_name               | Index name. The primary key is always named       |\n|                        | PRIMARY.                                          |\n+------------------------+---------------------------------------------------+\n| Seq_in_index           | The column\'s sequence in the index, beginning     |\n|                        | with 1.                                           |\n+------------------------+---------------------------------------------------+\n| Column_name            | Column name.                                      |\n+------------------------+---------------------------------------------------+\n| Collation              | Either A, if the column is sorted in ascending    |\n|                        | order in the index, or NULL if it\'s not sorted.   |\n+------------------------+---------------------------------------------------+\n| Cardinality            | Estimated number of unique values in the index.   |\n|                        | The cardinality statistics are calculated at      |\n|                        | various times, and can help the optimizer make    |\n|                        | improved decisions.                               |\n+------------------------+---------------------------------------------------+\n| Sub_part               | NULL if the entire column is included in the      |\n|                        | index, or the number of included characters if    |\n|                        | not.                                              |\n+------------------------+---------------------------------------------------+\n| Packed                 | NULL if the index is not packed, otherwise how    |\n|                        | the index is packed.                              |\n+------------------------+---------------------------------------------------+\n| Null                   | NULL if NULL values are permitted in the column,  |\n|                        | an empty string if NULLs are not permitted.       |\n+------------------------+---------------------------------------------------+\n| Index_type             | The index type, which can be BTREE, FULLTEXT,     |\n|                        | HASH or RTREE. See Storage Engine Index Types.    |\n+------------------------+---------------------------------------------------+\n| Comment                | Other information, such as whether the index is   |\n|                        | disabled.                                         |\n+------------------------+---------------------------------------------------+\n| Index_comment          | Contents of the COMMENT attribute when the index  |\n|                        | was created.                                      |\n+------------------------+---------------------------------------------------+\n| Ignored                | Whether or not an index will be ignored by the    |\n|                        | optimizer. See Ignored Indexes. From MariaDB      |\n|                        | 10.6.0.                                           |\n+------------------------+---------------------------------------------------+\n\nThe WHERE and LIKE clauses can be given to select rows using more general\nconditions, as discussed in Extended SHOW.\n\nExamples\n--------\n\nCREATE TABLE IF NOT EXISTS `employees_example` (\n `id` int(11) NOT NULL AUTO_INCREMENT,\n `first_name` varchar(30) NOT NULL,\n `last_name` varchar(40) NOT NULL,\n `position` varchar(25) NOT NULL,\n `home_address` varchar(50) NOT NULL,\n `home_phone` varchar(12) NOT NULL,\n `employee_code` varchar(25) NOT NULL,\n PRIMARY KEY (`id`),\n UNIQUE KEY `employee_code` (`employee_code`),\n KEY `first_name` (`first_name`,`last_name`)\n) ENGINE=Aria;\n\nINSERT INTO `employees_example` (`first_name`, `last_name`, `position`,\n`home_address`, `home_phone`, `employee_code`)\n VALUES\n (\'Mustapha\', \'Mond\', \'Chief Executive Officer\', \'692 Promiscuous Plaza\',\n\'326-555-3492\', \'MM1\'),\n (\'Henry\', \'Foster\', \'Store Manager\', \'314 Savage Circle\', \'326-555-3847\',\n\'HF1\'),\n (\'Bernard\', \'Marx\', \'Cashier\', \'1240 Ambient Avenue\', \'326-555-8456\', \'BM1\'),\n (\'Lenina\', \'Crowne\', \'Cashier\', \'281 Bumblepuppy Boulevard\', \'328-555-2349\',\n\'LC1\'),\n (\'Fanny\', \'Crowne\', \'Restocker\', \'1023 Bokanovsky Lane\', \'326-555-6329\',\n\'FC1\'),\n (\'Helmholtz\', \'Watson\', \'Janitor\', \'944 Soma Court\', \'329-555-2478\', \'HW1\');\n\nSHOW INDEXES FROM employees_example\\G\n*************************** 1. row ***************************\n    Table: employees_example\n Non_unique: 0\n  Key_name: PRIMARY\n Seq_in_index: 1\n Column_name: id\n  Collation: A\n Cardinality: 6\n  Sub_part: NULL\n   Packed: NULL\n    Null:\n Index_type: BTREE\n   Comment:\nIndex_comment: \n   Ignored: NO\n*************************** 2. row ***************************\n    Table: employees_example\n Non_unique: 0\n  Key_name: employee_code\n Seq_in_index: 1\n Column_name: employee_code\n  Collation: A\n Cardinality: 6\n  Sub_part: NULL\n   Packed: NULL\n    Null:\n Index_type: BTREE\n   Comment:\nIndex_comment: \n   Ignored: NO\n*************************** 3. row ***************************\n    Table: employees_example\n Non_unique: 1\n  Key_name: first_name\n Seq_in_index: 1\n Column_name: first_name\n  Collation: A\n Cardinality: NULL\n  Sub_part: NULL\n   Packed: NULL\n    Null:\n Index_type: BTREE\n   Comment:\nIndex_comment: \n   Ignored: NO\n*************************** 4. row ***************************\n    Table: employees_example\n Non_unique: 1\n  Key_name: first_name\n Seq_in_index: 2\n Column_name: last_name\n  Collation: A\n Cardinality: NULL\n  Sub_part: NULL\n   Packed: NULL\n    Null:\n Index_type: BTREE\n   Comment:\nIndex_comment: \n   Ignored: NO\n\nURL: https://mariadb.com/kb/en/show-index/','','https://mariadb.com/kb/en/show-index/'),
(342,'SHOW EXPLAIN',26,'Syntax\n------\n\nSHOW EXPLAIN [FORMAT=JSON] FOR <connection_id>;\nEXPLAIN [FORMAT=JSON] FOR CONNECTION <connection_id>;\n\nDescription\n-----------\n\nThe SHOW EXPLAIN command allows one to get an EXPLAIN (that is, a description\nof a query plan) of a query running in a certain connection.\n\nSHOW EXPLAIN FOR <connection_id>;\n\nwill produce an EXPLAIN output for the query that connection number\nconnection_id is running. The connection id can be obtained with SHOW\nPROCESSLIST.\n\nSHOW EXPLAIN FOR 1;\n+------+-------------+-------+-------+---------------+------+---------+------+-\n-------+-------------+\n| id   | select_type | table | type  | possible_keys | key  | key_len | ref  |\nrows    | Extra       |\n+------+-------------+-------+-------+---------------+------+---------+------+-\n-------+-------------+\n|    1 | SIMPLE      | tbl   | index | NULL          | a    | 5       | NULL |\n1000107 | Using index |\n+------+-------------+-------+-------+---------------+------+---------+------+-\n-------+-------------+\n1 row in set, 1 warning (0.00 sec)\n\nThe output is always accompanied with a warning which shows the query the\ntarget connection is running (this shows what the EXPLAIN is for):\n\nSHOW WARNINGS;\n+-------+------+------------------------+\n| Level | Code | Message                |\n+-------+------+------------------------+\n| Note  | 1003 | select sum(a) from tbl |\n+-------+------+------------------------+\n1 row in set (0.00 sec)\n\nEXPLAIN FOR CONNECTION\n----------------------\n\nMariaDB starting with 10.9\n--------------------------\nThe EXPLAIN FOR CONNECTION syntax was added for MySQL compatibility.\n\nFORMAT=JSON\n-----------\n\nMariaDB starting with 10.9\n--------------------------\nSHOW EXPLAIN [FORMAT=JSON] FOR <connection_id> extends SHOW EXPLAIN to return\nmore detailed JSON output.\n\nPossible Errors\n---------------\n\nThe output can be only produced if the target connection is currently running\na query, which has a ready query plan. If this is not the case, the output\nwill be:\n\nSHOW EXPLAIN FOR 2;\nERROR 1932 (HY000): Target is not running an EXPLAINable command\n\nYou will get this error when:\n\n* the target connection is not running a command for which one can run EXPLAIN\n* the target connection is running a command for which one can run EXPLAIN, but\nthere is no query plan yet (for example, tables are open and locks are\n acquired before the query plan is produced)\n\nDifferences Between SHOW EXPLAIN and EXPLAIN Outputs\n----------------------------------------------------\n\nBackground\n----------\n\nIn MySQL, EXPLAIN execution takes a slightly different route from the way the\nreal query (typically the SELECT) is optimized. This is unfortunate, and has\ncaused a number of bugs in EXPLAIN. (For example, see MDEV-326, MDEV-410, and\nlp:1013343. lp:992942 is not directly about EXPLAIN, but it also would not\nhave existed if MySQL didn\'t try to delete parts of a query plan in the middle\nof the query)\n\nSHOW EXPLAIN examines a running SELECT, and hence its output may be slightly\ndifferent from what EXPLAIN SELECT would produce. We did our best to make sure\nthat either the difference is negligible, or SHOW EXPLAIN\'s output is closer\nto reality than EXPLAIN\'s output.\n\nList of Recorded Differences\n----------------------------\n\n* SHOW EXPLAIN may have Extra=\'no matching row in const table\', where  EXPLAIN\nwould produce Extra=\'Impossible WHERE ...\'\n* For queries with subqueries, SHOW EXPLAIN may print select_type==PRIMARY\nwhere regular EXPLAIN used to print select_type==SIMPLE, or vice versa.\n\nRequired Permissions\n--------------------\n\nRunning SHOW EXPLAIN requires the same permissions as running SHOW PROCESSLIST\nwould.\n\nURL: https://mariadb.com/kb/en/show-explain/','','https://mariadb.com/kb/en/show-explain/'),
(344,'BACKUP LOCK',26,'MariaDB starting with 10.4.2\n----------------------------\nThe BACKUP LOCK command was introduced in MariaDB 10.4.2.\n\nBACKUP LOCK blocks a table from DDL statements. This is mainly intended to be\nused by tools like mariabackup that need to ensure there are no DDLs on a\ntable while the table files are opened. For example, for an Aria table that\nstores data in 3 files with extensions .frm, .MAI and .MAD. Normal read/write\noperations can continue as normal.\n\nSyntax\n------\n\nTo lock a table:\n\nBACKUP LOCK table_name\n\nTo unlock a table:\n\nBACKUP UNLOCK\n\nUsage in a Backup Tool\n----------------------\n\nBACKUP LOCK [database.]table_name;\n - Open all files related to a table (for example, t.frm, t.MAI and t.MYD)\nBACKUP UNLOCK;\n- Copy data\n- Close files\n\nThis ensures that all files are from the same generation, that is created at\nthe same time by the MariaDB server. This works, because the open files will\npoint to the original table files which will not be affected if there is any\nALTER TABLE while copying the files.\n\nPrivileges\n----------\n\nBACKUP LOCK requires the RELOAD privilege.\n\nNotes\n-----\n\n* The idea is that the BACKUP LOCK should be held for as short a time as\npossible by the backup tool. The time to take an uncontested lock is very\nshort! One can easily do 50,000 locks/unlocks per second on low end hardware.\n* One should use different connections for BACKUP STAGE commands and BACKUP\nLOCK.\n\nImplementation\n--------------\n\n* Internally, BACKUP LOCK is implemented by taking an MDLSHARED_HIGH_PRIO MDL\nlock on the table object, which protects the table from any DDL operations.\n\nURL: https://mariadb.com/kb/en/backup-lock/','','https://mariadb.com/kb/en/backup-lock/'),
(343,'BACKUP STAGE',26,'MariaDB starting with 10.4.1\n----------------------------\nThe BACKUP STAGE commands were introduced in MariaDB 10.4.1.\n\nThe BACKUP STAGE commands are a set of commands to make it possible to make an\nefficient external backup tool.\n\nSyntax\n------\n\nBACKUP STAGE [START | FLUSH | BLOCK_DDL | BLOCK_COMMIT | END ]\n\nIn the following text, a transactional table means InnoDB or \"InnoDB-like\nengine with redo log that can lock redo purges and can be copied without locks\nby an outside process\".\n\nGoals with BACKUP STAGE Commands\n--------------------------------\n\n* To be able to do a majority of the backup with the minimum possible server\nlocks. Especially for transactional tables (InnoDB, MyRocks etc) there is only\nneed for a very short block of new commits while copying statistics and log\ntables.\n* DDL are only needed to be blocked for a very short duration of the backup\nwhile mariabackup is copying the tables affected by DDL during the initial\npart of the backup.\n* Most non transactional tables (those that are not in use) will be copied\nduring BACKUP STAGE START.  The exceptions are system statistic and log tables\nthat are not blocked during the backup until BLOCK_COMMIT.\n* Should work efficiently with backup tools that use disk snapshots.\n* Should work as efficiently as possible for all table types that store data\non the local disks.\n* As little copying as possible under higher level stages/locks. For example,\n.frm (dictionary) and .trn (trigger) files should be copying while copying the\ntable data.\n\nBACKUP STAGE Commands\n---------------------\n\nBACKUP STAGE START\n------------------\n\nThe START stage is designed for the following tasks:\n\n* Blocks purge of redo files for storage engines that needs this (Aria)\n* Start logging of DDL commands into \'datadir\'/ddl.log. This may take a short\ntime as the command has to wait until there are no active DDL commands.\n\nBACKUP STAGE FLUSH\n------------------\n\nThe FLUSH stage is designed for the following tasks:\n\n* FLUSH all changes for inactive non-transactional tables, except for\nstatistics and log tables.\n* Close all tables that are not in use, to ensure they are marked as closed\nfor the backup.\n* BLOCK all new write locks for all non transactional tables (except\nstatistics and log tables).  The command will not wait for tables that are in\nuse by read-only transactions.\n\nDDLs don\'t have to be blocked at this stage as they can\'t cause the table to\nbe in an inconsistent state. This is true also for non-transactional tables.\n\nBACKUP STAGE BLOCK_DDL\n----------------------\n\nThe BLOCK_DDL stage is designed for the following tasks:\n\n* Wait for all statements using write locked non-transactional tables to end.\n* Blocks CREATE TABLE, DROP TABLE, TRUNCATE TABLE, and RENAME TABLE.\n* Blocks also start off a new ALTER TABLE and the final rename phase of ALTER\nTABLE. Running ALTER TABLES are not blocked.\n\nBACKUP STAGE BLOCK_COMMIT\n-------------------------\n\nThe BLOCK_COMMIT stage is designed for the following tasks:\n\n* Lock the binary log and commit/rollback to ensure that no changes are\ncommitted to any tables. If there are active commits or data to be copied to\nthe binary log this will be allowed to finish.  Active transactions will not\naffect BLOCK_COMMIT.\n* This doesn\'t lock temporary tables that are not used by replication. However\nthese will be blocked when it\'s time to write to the binary log.\n* Lock system log tables and statistics tables, flush them and mark them\nclosed.\n\nWhen the BLOCK_COMMIT\'s stages return, this is the \'backup time\'. Everything\ncommitted will be in the backup and everything not committed will roll back.\n\nTransactional engines will continue to do changes to the redo log during the\nBLOCK COMMIT stage, but this is not important as all of these will roll back\nlater as the changes will not be committed.\n\nBACKUP STAGE END\n----------------\n\nThe END stage is designed for the following tasks:\n\n* End DDL logging\n* Free resources\n\nUsing BACKUP STAGE Commands with Backup Tools\n---------------------------------------------\n\nUsing BACKUP STAGE Commands with Mariabackup\n--------------------------------------------\n\nThe BACKUP STAGE commands are a set of commands to make it possible to make an\nefficient external backup tool. How Mariabackup uses these commands depends on\nwhether you are using the version that is bundled with MariaDB Community\nServer or the version that is bundled with MariaDB Enterprise Server. See\nMariabackup and BACKUP STAGE Commands for some examples on how Mariabackup\nuses these commands.\n\nIf you would like to use a version of Mariabackup that uses the BACKUP STAGE\ncommands in an efficient way, then one option is to use MariaDB Enterprise\nBackup that is bundled with MariaDB Enterprise Server.\n\nUsing BACKUP STAGE Commands with Storage Snapshots\n--------------------------------------------------\n\nThe BACKUP STAGE commands are a set of commands to make it possible to make an\nefficient external backup tool. These commands could even be used by tools\nthat perform backups by taking a snapshot of a file system, SAN, or some other\nkind of storage device. See Storage Snapshots and BACKUP STAGE Commands for\nsome examples on how to use each BACKUP STAGE command in an efficient way.\n\nPrivileges\n----------\n\nBACKUP STAGE requires the RELOAD privilege.\n\nNotes\n-----\n\n* Only one connection can run BACKUP STAGE START. If a second connection\ntries, it will wait until the first one has executed BACKUP STAGE END.\n* If the user skips a BACKUP STAGE, then all intermediate backup stages will\nautomatically be run. This will allow us to add new stages within the BACKUP\nSTAGE hierarchy in the future with even more precise locks without causing\nproblems for tools using an earlier version of the BACKUP STAGE implementation.\n* One can use the max_statement_time or lock_wait_timeout system variables to\nensure that a BACKUP STAGE command doesn\'t block the server too long.\n* DDL logging will only be available in MariaDB Enterprise Server 10.2 and\nlater.\n* A disconnect will automatically release backup stages.\n* There is no easy way to see which is the current stage.\n\nURL: https://mariadb.com/kb/en/backup-stage/','','https://mariadb.com/kb/en/backup-stage/'),
(347,'FLUSH TABLES FOR EXPORT',26,'Syntax\n------\n\nFLUSH TABLES table_name [, table_name] FOR EXPORT\n\nDescription\n-----------\n\nFLUSH TABLES ... FOR EXPORT flushes changes to the specified tables to disk so\nthat binary copies can be made while the server is still running. This works\nfor Archive, Aria, CSV, InnoDB, MyISAM, MERGE, and XtraDB tables.\n\nThe table is read locked until one has issued UNLOCK TABLES.\n\nIf a storage engine does not support FLUSH TABLES FOR EXPORT, a 1031 error\n(SQLSTATE \'HY000\') is produced.\n\nIf FLUSH TABLES ... FOR EXPORT is in effect in the session, the following\nstatements will produce an error if attempted:\n\n* FLUSH TABLES WITH READ LOCK\n* FLUSH TABLES ... WITH READ LOCK\n* FLUSH TABLES ... FOR EXPORT\n* Any statement trying to update any table\n\nIf any of the following statements is in effect in the session, attempting\nFLUSH TABLES ... FOR EXPORT will produce an error.\n\n* FLUSH TABLES ... WITH READ LOCK\n* FLUSH TABLES ... FOR EXPORT\n* LOCK TABLES ... READ\n* LOCK TABLES ... WRITE\n\nFLUSH FOR EXPORT is not written to the binary log.\n\nThis statement requires the RELOAD and the LOCK TABLES privileges.\n\nIf one of the specified tables cannot be locked, none of the tables will be\nlocked.\n\nIf a table does not exist, an error like the following will be produced:\n\nERROR 1146 (42S02): Table \'test.xxx\' doesn\'t exist\n\nIf a table is a view, an error like the following will be produced:\n\nERROR 1347 (HY000): \'test.v\' is not BASE TABLE\n\nExample\n-------\n\nFLUSH TABLES test.t1 FOR EXPORT;\n#  Copy files related to the table (see below)\nUNLOCK TABLES;\n\nFor a full description, please see copying MariaDB tables.\n\nURL: https://mariadb.com/kb/en/flush-tables-for-export/','','https://mariadb.com/kb/en/flush-tables-for-export/'),
(348,'SHOW RELAYLOG EVENTS',26,'The terms master and slave have historically been used in replication, but the\nterms terms primary and replica are now preferred. The old terms are used\nstill used in parts of the documentation, and in MariaDB commands, although\nMariaDB 10.5 has begun the process of renaming. The documentation process is\nongoing. See MDEV-18777 to follow progress on this effort.\n\nSyntax\n------\n\nSHOW RELAYLOG [\'connection_name\'] EVENTS\n  [IN \'log_name\'] [FROM pos] [LIMIT [offset,] row_count]\n  [ FOR CHANNEL \'channel_name\']\n\nDescription\n-----------\n\nOn replicas, this command shows the events in the relay log. If \'log_name\' is\nnot specified, the first relay log is shown.\n\nSyntax for the LIMIT clause is the same as for SELECT ... LIMIT.\n\nUsing the LIMIT clause is highly recommended because the SHOW RELAYLOG EVENTS\ncommand returns the complete contents of the relay log, which can be quite\nlarge.\n\nThis command does not return events related to setting user and system\nvariables. If you need those, use mariadb-binlog.\n\nOn the primary, this command does nothing.\n\nRequires the REPLICA MONITOR privilege (>= MariaDB 10.5.9), the REPLICATION\nSLAVE ADMIN privilege (>= MariaDB 10.5.2) or the REPLICATION SLAVE privilege\n(<= MariaDB 10.5.1).\n\nconnection_name\n---------------\n\nIf there is only one nameless primary, or the default primary (as specified by\nthe default_master_connection system variable) is intended, connection_name\ncan be omitted. If provided, the SHOW RELAYLOG statement will apply to the\nspecified primary. connection_name is case-insensitive.\n\nMariaDB starting with 10.7.0\n----------------------------\nThe FOR CHANNEL keyword was added for MySQL compatibility. This is identical\nas using the channel_name directly after SHOW RELAYLOG.\n\nURL: https://mariadb.com/kb/en/show-relaylog-events/','','https://mariadb.com/kb/en/show-relaylog-events/'),
(350,'SHOW MASTER STATUS',26,'Syntax\n------\n\nSHOW MASTER STATUS\nSHOW BINLOG STATUS -- From MariaDB 10.5.2\n\nDescription\n-----------\n\nProvides status information about the binary log files of the primary.\n\nThis statement requires the SUPER privilege, the REPLICATION_CLIENT privilege,\nor, from MariaDB 10.5.2, the BINLOG MONITOR privilege.\n\nTo see information about the current GTIDs in the binary log, use the\ngtid_binlog_pos variable.\n\nSHOW MASTER STATUS was renamed to SHOW BINLOG STATUS in MariaDB 10.5.2, but\nthe old name remains an alias for compatibility purposes.\n\nExample\n-------\n\nSHOW MASTER STATUS;\n+--------------------+----------+--------------+------------------+\n| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |\n+--------------------+----------+--------------+------------------+\n| mariadb-bin.000016 |      475 |              |                  |\n+--------------------+----------+--------------+------------------+\nSELECT @@global.gtid_binlog_pos;\n+--------------------------+\n| @@global.gtid_binlog_pos |\n+--------------------------+\n| 0-1-2                    |\n+--------------------------+\n\nURL: https://mariadb.com/kb/en/show-binlog-status/','','https://mariadb.com/kb/en/show-binlog-status/'),
(351,'SHOW SLAVE HOSTS',26,'Syntax\n------\n\nSHOW SLAVE HOSTS\nSHOW REPLICA HOSTS -- from MariaDB 10.5.1\n\nDescription\n-----------\n\nThis command is run on the primary and displays a list of replicas that are\ncurrently registered with it. Only replicas started with the\n--report-host=host_name option are visible in this list.\n\nThe output looks like this:\n\nSHOW SLAVE HOSTS;\n+------------+-----------+------+-----------+\n| Server_id  | Host      | Port | Master_id |\n+------------+-----------+------+-----------+\n|  192168010 | iconnect2 | 3306 | 192168011 |\n| 1921680101 | athena    | 3306 | 192168011 |\n+------------+-----------+------+-----------+\n\n* Server_id: The unique server ID of the replica server, as configured in the\nserver\'s option file, or on the command line with --server-id=value.\n* Host: The host name of the replica server, as configured in the server\'s\noption file, or on the command line with --report-host=host_name. Note that\nthis can differ from the machine name as configured in the operating system.\n* Port: The port the replica server is listening on.\n* Master_id: The unique server ID of the primary server that the replica\nserver is replicating from.\n\nSome MariaDB and MySQL versions report another variable, rpl_recovery_rank.\nThis variable was never used, and was eventually removed in MariaDB 10.1.2 .\n\nRequires the REPLICATION MASTER ADMIN privilege (>= MariaDB 10.5.2) or the\nREPLICATION SLAVE privilege (<= MariaDB 10.5.1).\n\nSHOW REPLICA HOSTS\n------------------\n\nMariaDB starting with 10.5.1\n----------------------------\nSHOW REPLICA HOSTS is an alias for SHOW SLAVE HOSTS from MariaDB 10.5.1.\n\nURL: https://mariadb.com/kb/en/show-replica-hosts/','','https://mariadb.com/kb/en/show-replica-hosts/'),
(352,'SHOW PLUGINS',26,'Syntax\n------\n\nSHOW PLUGINS;\n\nDescription\n-----------\n\nSHOW PLUGINS displays information about installed plugins. The Library column\nindicates the plugin library - if it is NULL, the plugin is built-in and\ncannot be uninstalled.\n\nThe PLUGINS table in the information_schema database contains more detailed\ninformation.\n\nFor specific information about storage engines (a particular type of plugin),\nsee the information_schema.ENGINES table and the SHOW ENGINES statement.\n\nExamples\n--------\n\nSHOW PLUGINS;\n+----------------------------+----------+--------------------+-------------+---\n-----+\n| Name                       | Status   | Type               | Library     |\nLicense |\n+----------------------------+----------+--------------------+-------------+---\n-----+\n| binlog                     | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| mysql_native_password      | ACTIVE   | AUTHENTICATION     | NULL        |\nGPL     |\n| mysql_old_password         | ACTIVE   | AUTHENTICATION     | NULL        |\nGPL     |\n| MRG_MyISAM                 | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| MyISAM                     | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| CSV                        | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| MEMORY                     | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| FEDERATED                  | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| PERFORMANCE_SCHEMA         | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| Aria                       | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| InnoDB                     | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| INNODB_TRX                 | ACTIVE   | INFORMATION SCHEMA | NULL        |\nGPL     |\n...\n| INNODB_SYS_FOREIGN         | ACTIVE   | INFORMATION SCHEMA | NULL        |\nGPL     |\n| INNODB_SYS_FOREIGN_COLS    | ACTIVE   | INFORMATION SCHEMA | NULL        |\nGPL     |\n| SPHINX                     | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| ARCHIVE                    | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| BLACKHOLE                  | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| FEEDBACK                   | DISABLED | INFORMATION SCHEMA | NULL        |\nGPL     |\n| partition                  | ACTIVE   | STORAGE ENGINE     | NULL        |\nGPL     |\n| pam                        | ACTIVE   | AUTHENTICATION     | auth_pam.so |\nGPL     |\n+----------------------------+----------+--------------------+-------------+---\n-----+\n\nURL: https://mariadb.com/kb/en/show-plugins/','','https://mariadb.com/kb/en/show-plugins/'),
(353,'SHOW PLUGINS SONAME',26,'Syntax\n------\n\nSHOW PLUGINS SONAME { library | LIKE \'pattern\' | WHERE expr };\n\nDescription\n-----------\n\nSHOW PLUGINS SONAME displays information about compiled-in and all server\nplugins in the plugin_dir directory, including plugins that haven\'t been\ninstalled.\n\nExamples\n--------\n\nSHOW PLUGINS SONAME \'ha_example.so\';\n+----------+---------------+----------------+---------------+---------+\n| Name     | Status        | Type           | Library       | License |\n+----------+---------------+----------------+---------------+---------+\n| EXAMPLE  | NOT INSTALLED | STORAGE ENGINE | ha_example.so | GPL     |\n| UNUSABLE | NOT INSTALLED | DAEMON         | ha_example.so | GPL     |\n+----------+---------------+----------------+---------------+---------+\n\nThere is also a corresponding information_schema table, called ALL_PLUGINS,\nwhich contains more complete information.\n\nURL: https://mariadb.com/kb/en/show-plugins-soname/','','https://mariadb.com/kb/en/show-plugins-soname/'),
(355,'SET CHARACTER SET',26,'Syntax\n------\n\nSET {CHARACTER SET | CHARSET}\n  {charset_name | DEFAULT}\n\nDescription\n-----------\n\nSets the character_set_client and character_set_results session system\nvariables to the specified character set and collation_connection to the value\nof collation_database, which implicitly sets character_set_connection to the\nvalue of character_set_database.\n\nThis maps all strings sent between the current client and the server with the\ngiven mapping.\n\nExample\n-------\n\nSHOW VARIABLES LIKE \'character_set\\_%\';\n+--------------------------+--------+\n| Variable_name            | Value  |\n+--------------------------+--------+\n| character_set_client     | utf8   |\n| character_set_connection | utf8   |\n| character_set_database   | latin1 |\n| character_set_filesystem | binary |\n| character_set_results    | utf8   |\n| character_set_server     | latin1 |\n| character_set_system     | utf8   |\n+--------------------------+--------+\n\nSHOW VARIABLES LIKE \'collation%\';\n+----------------------+-------------------+\n| Variable_name        | Value             |\n+----------------------+-------------------+\n| collation_connection | utf8_general_ci   |\n| collation_database   | latin1_swedish_ci |\n| collation_server     | latin1_swedish_ci |\n+----------------------+-------------------+\n\nSET CHARACTER SET utf8mb4;\n\nSHOW VARIABLES LIKE \'character_set\\_%\';\n+--------------------------+---------+\n| Variable_name            | Value   |\n+--------------------------+---------+\n| character_set_client     | utf8mb4 |\n| character_set_connection | latin1  |\n| character_set_database   | latin1  |\n| character_set_filesystem | binary  |\n| character_set_results    | utf8mb4 |\n| character_set_server     | latin1  |\n| character_set_system     | utf8    |\n+--------------------------+---------+\n\nSHOW VARIABLES LIKE \'collation%\';\n+----------------------+-------------------+\n| Variable_name        | Value             |\n+----------------------+-------------------+\n| collation_connection | latin1_swedish_ci |\n| collation_database   | latin1_swedish_ci |\n| collation_server     | latin1_swedish_ci |\n+----------------------+-------------------+\n\nURL: https://mariadb.com/kb/en/set-character-set/','','https://mariadb.com/kb/en/set-character-set/'),
(354,'SET',26,'Syntax\n------\n\nSET variable_assignment [, variable_assignment] ...\n\nvariable_assignment:\n   user_var_name = expr\n  | [GLOBAL | SESSION] system_var_name = expr\n  | [@@global. | @@session. | @@]system_var_name = expr\n\nOne can also set a user variable in any expression with this syntax:\n\nuser_var_name:= expr\n\nDescription\n-----------\n\nThe SET statement assigns values to different types of variables that affect\nthe operation of the server or your client. Older versions of MySQL employed\nSET OPTION, but this syntax was deprecated in favor of SET without OPTION, and\nwas removed in MariaDB 10.0.\n\nChanging a system variable by using the SET statement does not make the change\npermanently. To do so, the change must be made in a configuration file.\n\nFor setting variables on a per-query basis, see SET STATEMENT.\n\nSee SHOW VARIABLES for documentation on viewing server system variables.\n\nSee Server System Variables for a list of all the system variables.\n\nGLOBAL / SESSION\n----------------\n\nWhen setting a system variable, the scope can be specified as either GLOBAL or\nSESSION.\n\nA global variable change affects all new sessions. It does not affect any\ncurrently open sessions, including the one that made the change.\n\nA session variable change affects the current session only.\n\nIf the variable has a session value, not specifying either GLOBAL or SESSION\nwill be the same as specifying SESSION. If the variable only has a global\nvalue, not specifying GLOBAL or SESSION will apply to the change to the global\nvalue.\n\nDEFAULT\n-------\n\nSetting a global variable to DEFAULT will restore it to the server default,\nand setting a session variable to DEFAULT will restore it to the current\nglobal value.\n\nExamples\n--------\n\n* innodb_sync_spin_loops is a global variable.\n* skip_parallel_replication is a session variable.\n* max_error_count is both global and session.\n\nSELECT VARIABLE_NAME, SESSION_VALUE, GLOBAL_VALUE FROM\n INFORMATION_SCHEMA.SYSTEM_VARIABLES WHERE \n VARIABLE_NAME IN (\'max_error_count\', \'skip_parallel_replication\',\n\'innodb_sync_spin_loops\');\n+---------------------------+---------------+--------------+\n| VARIABLE_NAME             | SESSION_VALUE | GLOBAL_VALUE |\n+---------------------------+---------------+--------------+\n| MAX_ERROR_COUNT           | 64            | 64           |\n| SKIP_PARALLEL_REPLICATION | OFF           | NULL         |\n| INNODB_SYNC_SPIN_LOOPS    | NULL          | 30           |\n+---------------------------+---------------+--------------+\n\nSetting the session values:\n\nSET max_error_count=128;Query OK, 0 rows affected (0.000 sec)\n\nSET skip_parallel_replication=ON;Query OK, 0 rows affected (0.000 sec)\n\nSET innodb_sync_spin_loops=60;\nERROR 1229 (HY000): Variable \'innodb_sync_spin_loops\' is a GLOBAL variable \n and should be set with SET GLOBAL\n\nSELECT VARIABLE_NAME, SESSION_VALUE, GLOBAL_VALUE FROM\n INFORMATION_SCHEMA.SYSTEM_VARIABLES WHERE \n VARIABLE_NAME IN (\'max_error_count\', \'skip_parallel_replication\',\n\'innodb_sync_spin_loops\');\n+---------------------------+---------------+--------------+\n| VARIABLE_NAME             | SESSION_VALUE | GLOBAL_VALUE |\n+---------------------------+---------------+--------------+\n| MAX_ERROR_COUNT           | 128           | 64           |\n| SKIP_PARALLEL_REPLICATION | ON            | NULL         |\n| INNODB_SYNC_SPIN_LOOPS    | NULL          | 30           |\n+---------------------------+---------------+--------------+\n\nSetting the global values:\n\nSET GLOBAL max_error_count=256;\n\nSET GLOBAL skip_parallel_replication=ON;\nERROR 1228 (HY000): Variable \'skip_parallel_replication\' is a SESSION variable \n and can\'t be used with SET GLOBAL\n\nSET GLOBAL innodb_sync_spin_loops=120;\n\nSELECT VARIABLE_NAME, SESSION_VALUE, GLOBAL_VALUE FROM\n INFORMATION_SCHEMA.SYSTEM_VARIABLES WHERE \n VARIABLE_NAME IN (\'max_error_count\', \'skip_parallel_replication\',\n\'innodb_sync_spin_loops\');\n+---------------------------+---------------+--------------+\n| VARIABLE_NAME             | SESSION_VALUE | GLOBAL_VALUE |\n+---------------------------+---------------+--------------+\n| MAX_ERROR_COUNT           | 128           | 256          |\n| SKIP_PARALLEL_REPLICATION | ON            | NULL         |\n| INNODB_SYNC_SPIN_LOOPS    | NULL          | 120          |\n+---------------------------+---------------+--------------+\n\nSHOW VARIABLES will by default return the session value unless the variable is\nglobal only.\n\nSHOW VARIABLES LIKE \'max_error_count\';\n+-----------------+-------+\n| Variable_name   | Value |\n+-----------------+-------+\n| max_error_count | 128   |\n+-----------------+-------+\n\nSHOW VARIABLES LIKE \'skip_parallel_replication\';\n+---------------------------+-------+\n| Variable_name             | Value |\n+---------------------------+-------+\n| skip_parallel_replication | ON    |\n+---------------------------+-------+\n\nSHOW VARIABLES LIKE \'innodb_sync_spin_loops\';\n+------------------------+-------+\n| Variable_name          | Value |\n+------------------------+-------+\n| innodb_sync_spin_loops | 120   |\n+------------------------+-------+\n\nUsing the inplace syntax:\n\nSELECT (@a:=1);\n+---------+\n| (@a:=1) |\n+---------+\n|       1 |\n+---------+\n\nSELECT @a;\n+------+\n| @a   |\n+------+\n|    1 |\n+------+\n\nURL: https://mariadb.com/kb/en/set/','','https://mariadb.com/kb/en/set/'),
(356,'SET NAMES',26,'Syntax\n------\n\nSET NAMES {\'charset_name\'\n  [COLLATE \'collation_name\'] | DEFAULT}\n\nDescription\n-----------\n\nSets the character_set_client, character_set_connection, character_set_results\nand, implicitly, the collation_connection session system variables to the\nspecified character set and collation.\n\nThis determines which character set the client will use to send statements to\nthe server, and the server will use for sending results back to the client.\n\nucs2, utf16, utf16le and utf32 are not valid character sets for SET NAMES, as\nthey cannot be used as client character sets.\n\nThe collation clause is optional. If not defined (or if DEFAULT is specified),\nthe default collation for the character set will be used.\n\nQuotes are optional for the character set or collation clauses.\n\nExamples\n--------\n\nSELECT VARIABLE_NAME, SESSION_VALUE \n FROM INFORMATION_SCHEMA.SYSTEM_VARIABLES WHERE\n VARIABLE_NAME LIKE \'character_set_c%\' OR\n VARIABLE_NAME LIKE \'character_set_re%\' OR\n VARIABLE_NAME LIKE \'collation_c%\';\n+--------------------------+-----------------+\n| VARIABLE_NAME            | SESSION_VALUE   |\n+--------------------------+-----------------+\n| CHARACTER_SET_RESULTS    | utf8            |\n| CHARACTER_SET_CONNECTION | utf8            |\n| CHARACTER_SET_CLIENT     | utf8            |\n| COLLATION_CONNECTION     | utf8_general_ci |\n+--------------------------+-----------------+\n\nSET NAMES big5;\n\nSELECT VARIABLE_NAME, SESSION_VALUE \n FROM INFORMATION_SCHEMA.SYSTEM_VARIABLES WHERE\n VARIABLE_NAME LIKE \'character_set_c%\' OR\n VARIABLE_NAME LIKE \'character_set_re%\' OR\n VARIABLE_NAME LIKE \'collation_c%\';\n+--------------------------+-----------------+\n| VARIABLE_NAME            | SESSION_VALUE   |\n+--------------------------+-----------------+\n| CHARACTER_SET_RESULTS    | big5            |\n| CHARACTER_SET_CONNECTION | big5            |\n| CHARACTER_SET_CLIENT     | big5            |\n| COLLATION_CONNECTION     | big5_chinese_ci |\n+--------------------------+-----------------+\n\nSET NAMES \'latin1\' COLLATE \'latin1_bin\';\n\nSELECT VARIABLE_NAME, SESSION_VALUE \n FROM INFORMATION_SCHEMA.SYSTEM_VARIABLES WHERE\n VARIABLE_NAME LIKE \'character_set_c%\' OR\n VARIABLE_NAME LIKE \'character_set_re%\' OR\n VARIABLE_NAME LIKE \'collation_c%\';\n+--------------------------+---------------+\n| VARIABLE_NAME            | SESSION_VALUE |\n+--------------------------+---------------+\n| CHARACTER_SET_RESULTS    | latin1        |\n| CHARACTER_SET_CONNECTION | latin1        |\n| CHARACTER_SET_CLIENT     | latin1        |\n| COLLATION_CONNECTION     | latin1_bin    |\n+--------------------------+---------------+\n\nSET NAMES DEFAULT;\n\nSELECT VARIABLE_NAME, SESSION_VALUE \n FROM INFORMATION_SCHEMA.SYSTEM_VARIABLES WHERE\n VARIABLE_NAME LIKE \'character_set_c%\' OR\n VARIABLE_NAME LIKE \'character_set_re%\' OR\n VARIABLE_NAME LIKE \'collation_c%\';\n+--------------------------+-------------------+\n| VARIABLE_NAME            | SESSION_VALUE     |\n+--------------------------+-------------------+\n| CHARACTER_SET_RESULTS    | latin1            |\n| CHARACTER_SET_CONNECTION | latin1            |\n| CHARACTER_SET_CLIENT     | latin1            |\n| COLLATION_CONNECTION     | latin1_swedish_ci |\n+--------------------------+-------------------+\n\nURL: https://mariadb.com/kb/en/set-names/','','https://mariadb.com/kb/en/set-names/'),
(358,'SET STATEMENT',26,'MariaDB starting with 10.1.2\n----------------------------\nPer-query variables were introduced in MariaDB 10.1.2\n\nSET STATEMENT can be used to set the value of a system variable for the\nduration of the statement. It is also possible to set multiple variables.\n\nSyntax\n------\n\nSET STATEMENT var1=value1 [, var2=value2, ...] \n FOR <statement>\n\nwhere varN is a system variable (list of allowed variables is provided below),\nand valueN is a constant literal.\n\nDescription\n-----------\n\nSET STATEMENT var1=value1 FOR stmt\n\nis roughly equivalent to\n\nSET @save_value=@@var1;\nSET SESSION var1=value1;\nstmt;\nSET SESSION var1=@save_value;\n\nThe server parses the whole statement before executing it, so any variables\nset in this fashion that affect the parser may not have the expected effect.\nExamples include the charset variables, sql_mode=ansi_quotes, etc.\n\nExamples\n--------\n\nOne can limit statement execution time max_statement_time:\n\nSET STATEMENT max_statement_time=1000 FOR SELECT ... ;\n\nOne can switch on/off individual optimizations:\n\nSET STATEMENT optimizer_switch=\'materialization=off\' FOR SELECT ....;\n\nIt is possible to enable MRR/BKA for a query:\n\nSET STATEMENT  join_cache_level=6, optimizer_switch=\'mrr=on\'  FOR SELECT ...\n\nNote that it makes no sense to try to set a session variable inside a SET\nSTATEMENT:\n\n#USELESS STATEMENT\nSET STATEMENT sort_buffer_size = 100000 for SET SESSION sort_buffer_size =\n200000;\n\nFor the above, after setting sort_buffer_size to 200000 it will be reset to\nits original state (the state before the SET STATEMENT started) after the\nstatement execution.\n\nLimitations\n-----------\n\nThere are a number of variables that cannot be set on per-query basis. These\ninclude:\n\n* autocommit\n* character_set_client\n* character_set_connection\n* character_set_filesystem\n* collation_connection\n* default_master_connection\n* debug_sync\n* interactive_timeout\n* gtid_domain_id\n* last_insert_id\n* log_slow_filter\n* log_slow_rate_limit\n* log_slow_verbosity\n* long_query_time\n* min_examined_row_limit\n* profiling\n* profiling_history_size\n* query_cache_type\n* rand_seed1\n* rand_seed2\n* skip_replication\n* slow_query_log\n* sql_log_off\n* tx_isolation\n* wait_timeout\n\nSource\n------\n\n* The feature was originally implemented as a Google Summer of Code 2009\nproject by Joseph Lukas. \n* Percona Server 5.6 included it as Per-query variable statement\n* MariaDB ported the patch and fixed many bugs. The task in MariaDB Jira is\nMDEV-5231.\n\nURL: https://mariadb.com/kb/en/set-statement/','','https://mariadb.com/kb/en/set-statement/'),
(359,'SET Variable',26,'Syntax\n------\n\nSET var_name = expr [, var_name = expr] ...\n\nDescription\n-----------\n\nThe SET statement in stored programs is an extended version of the general SET\nstatement. Referenced variables may be ones declared inside a stored program,\nglobal system variables, or user-defined variables.\n\nThe SET statement in stored programs is implemented as part of the\npre-existing SET syntax. This allows an extended syntax of SET a=x, b=y, ...\nwhere different variable types (locally declared variables, global and session\nserver variables, user-defined variables) can be mixed. This also allows\ncombinations of local variables and some options that make sense only for\nsystem variables; in that case, the options are recognized but ignored.\n\nSET can be used with both local variables and user-defined variables.\n\nWhen setting several variables using the columns returned by a query, SELECT\nINTO should be preferred.\n\nTo set many variables to the same value, the LAST_VALUE( ) function can be\nused.\n\nBelow is an example of how a user-defined variable may be set:\n\nSET @x = 1;\n\nURL: https://mariadb.com/kb/en/set-variable/','','https://mariadb.com/kb/en/set-variable/'),
(360,'About SHOW',26,'SHOW has many forms that provide information about databases, tables, columns,\nor status information about the server. These include:\n\n* SHOW AUTHORS\n* SHOW CHARACTER SET [like_or_where]\n* SHOW COLLATION [like_or_where]\n* SHOW [FULL] COLUMNS FROM tbl_name [FROM db_name] [like_or_where]\n* SHOW CONTRIBUTORS\n* SHOW CREATE DATABASE db_name\n* SHOW CREATE EVENT event_name\n* SHOW CREATE PACKAGE package_name\n* SHOW CREATE PACKAGE BODY package_name\n* SHOW CREATE PROCEDURE proc_name\n* SHOW CREATE TABLE tbl_name\n* SHOW CREATE TRIGGER trigger_name\n* SHOW CREATE VIEW view_name\n* SHOW DATABASES [like_or_where]\n* SHOW ENGINE engine_name {STATUS | MUTEX}\n* SHOW [STORAGE] ENGINES\n* SHOW ERRORS [LIMIT [offset,] row_count]\n* SHOW [FULL] EVENTS\n* SHOW FUNCTION CODE func_name\n* SHOW FUNCTION STATUS [like_or_where]\n* SHOW GRANTS FOR user\n* SHOW INDEX FROM tbl_name [FROM db_name]\n* SHOW INNODB STATUS\n* SHOW OPEN TABLES [FROM db_name] [like_or_where]\n* SHOW PLUGINS\n* SHOW PROCEDURE CODE proc_name\n* SHOW PROCEDURE STATUS [like_or_where]\n* SHOW PRIVILEGES\n* SHOW [FULL] PROCESSLIST\n* SHOW PROFILE [types] [FOR QUERY n] [OFFSET n] [LIMIT n]\n* SHOW PROFILES\n* SHOW [GLOBAL | SESSION] STATUS [like_or_where]\n* SHOW TABLE STATUS [FROM db_name] [like_or_where]\n* SHOW TABLES [FROM db_name] [like_or_where]\n* SHOW TRIGGERS [FROM db_name] [like_or_where]\n* SHOW [GLOBAL | SESSION] VARIABLES [like_or_where]\n* SHOW WARNINGS [LIMIT [offset,] row_count]\n\nlike_or_where:\n  LIKE \'pattern\'\n | WHERE expr\n\nIf the syntax for a given SHOW statement includes a LIKE \'pattern\' part,\n\'pattern\' is a string that can contain the SQL \"%\" and \"_\" wildcard\ncharacters. The pattern is useful for restricting statement output to matching\nvalues.\n\nSeveral SHOW statements also accept a WHERE clause that provides more\nflexibility in specifying which rows to display. See Extended Show.\n\nURL: https://mariadb.com/kb/en/about-show/','','https://mariadb.com/kb/en/about-show/'),
(363,'SHOW BINARY LOGS',26,'Syntax\n------\n\nSHOW BINARY LOGS\nSHOW MASTER LOGS\n\nDescription\n-----------\n\nLists the binary log files on the server. This statement is used as part of\nthe procedure described in PURGE BINARY LOGS, that shows how to determine\nwhich logs can be purged.\n\nThis statement requires the SUPER privilege, the REPLICATION_CLIENT privilege,\nor, from MariaDB 10.5.2, the BINLOG MONITOR privilege.\n\nExamples\n--------\n\nSHOW BINARY LOGS;\n+--------------------+-----------+\n| Log_name           | File_size |\n+--------------------+-----------+\n| mariadb-bin.000001 |     19039 |\n| mariadb-bin.000002 |    717389 |\n| mariadb-bin.000003 |       300 |\n| mariadb-bin.000004 |       333 |\n| mariadb-bin.000005 |       899 |\n| mariadb-bin.000006 |       125 |\n| mariadb-bin.000007 |     18907 |\n| mariadb-bin.000008 |     19530 |\n| mariadb-bin.000009 |       151 |\n| mariadb-bin.000010 |       151 |\n| mariadb-bin.000011 |       125 |\n| mariadb-bin.000012 |       151 |\n| mariadb-bin.000013 |       151 |\n| mariadb-bin.000014 |       125 |\n| mariadb-bin.000015 |       151 |\n| mariadb-bin.000016 |       314 |\n+--------------------+-----------+\n\nURL: https://mariadb.com/kb/en/show-binary-logs/','','https://mariadb.com/kb/en/show-binary-logs/'),
(364,'SHOW BINLOG EVENTS',26,'Syntax\n------\n\nSHOW BINLOG EVENTS\n [IN \'log_name\'] [FROM pos] [LIMIT [offset,] row_count]\n\nDescription\n-----------\n\nShows the events in the binary log. If you do not specify \'log_name\', the\nfirst binary log is displayed.\n\nRequires the BINLOG MONITOR privilege (>= MariaDB 10.5.2) or the REPLICATION\nSLAVE privilege (<= MariaDB 10.5.1).\n\nExample\n-------\n\nSHOW BINLOG EVENTS IN \'mysql_sandbox10019-bin.000002\';\n+-------------------------------+-----+-------------------+-----------+--------\n----+------------------------------------------------+\n| Log_name                      | Pos | Event_type        | Server_id |\nEnd_log_pos | Info                                           |\n+-------------------------------+-----+-------------------+-----------+--------\n----+------------------------------------------------+\n| mysql_sandbox10019-bin.000002 |   4 | Format_desc       |         1 |       \n 248 | Server ver: 10.0.19-MariaDB-log, Binlog ver: 4 |\n| mysql_sandbox10019-bin.000002 | 248 | Gtid_list         |         1 |       \n 273 | []                                             |\n| mysql_sandbox10019-bin.000002 | 273 | Binlog_checkpoint |         1 |       \n 325 | mysql_sandbox10019-bin.000002                  |\n| mysql_sandbox10019-bin.000002 | 325 | Gtid              |         1 |       \n 363 | GTID 0-1-1                                     |\n| mysql_sandbox10019-bin.000002 | 363 | Query             |         1 |       \n 446 | CREATE DATABASE blog                           |\n| mysql_sandbox10019-bin.000002 | 446 | Gtid              |         1 |       \n 484 | GTID 0-1-2                                     |\n| mysql_sandbox10019-bin.000002 | 484 | Query             |         1 |       \n 571 | use `blog`; CREATE TABLE bb (id INT)           |\n+-------------------------------+-----+-------------------+-----------+--------\n----+------------------------------------------------+\n\nURL: https://mariadb.com/kb/en/show-binlog-events/','','https://mariadb.com/kb/en/show-binlog-events/'),
(361,'Extended Show',26,'The following SHOW statements can be extended by using a WHERE clause and a\nLIKE clause to refine the results:\n\n* SHOW CHARACTER SET\n* SHOW COLLATION\n* SHOW COLUMNS\n* SHOW DATABASES\n* SHOW FUNCTION STATUS\n* SHOW INDEX\n* SHOW OPEN TABLES\n* SHOW PACKAGE STATUS\n* SHOW PACKAGE BODY STATUS\n* SHOW INDEX\n* SHOW PROCEDURE STATUS\n* SHOW STATUS\n* SHOW TABLE STATUS\n* SHOW TABLES\n* SHOW TRIGGERS\n* SHOW VARIABLES\n\nAs with a regular SELECT, the WHERE clause can be used for the specific\ncolumns returned, and the LIKE clause with the regular wildcards.\n\nExamples\n--------\n\nSHOW TABLES;\n+----------------------+\n| Tables_in_test       |\n+----------------------+\n| animal_count         |\n| animals              |\n| are_the_mooses_loose |\n| aria_test2           |\n| t1                   |\n| view1                |\n+----------------------+\n\nShowing the tables beginning with a only.\n\nSHOW TABLES WHERE Tables_in_test LIKE \'a%\';\n+----------------------+\n| Tables_in_test       |\n+----------------------+\n| animal_count         |\n| animals              |\n| are_the_mooses_loose |\n| aria_test2           |\n+----------------------+\n\nVariables whose name starts with aria and with a valued of greater than 8192:\n\nSHOW VARIABLES WHERE Variable_name LIKE \'aria%\' AND Value >8192;\n+------------------------------+---------------------+\n| Variable_name                | Value               |\n+------------------------------+---------------------+\n| aria_checkpoint_log_activity | 1048576             |\n| aria_log_file_size           | 1073741824          |\n| aria_max_sort_file_size      | 9223372036853727232 |\n| aria_pagecache_buffer_size   | 134217728           |\n| aria_sort_buffer_size        | 134217728           |\n+------------------------------+---------------------+\n\nShortcut, just returning variables whose name begins with aria.\n\nSHOW VARIABLES LIKE \'aria%\';\n+------------------------------------------+---------------------+\n| Variable_name                            | Value               |\n+------------------------------------------+---------------------+\n| aria_block_size                          | 8192                |\n| aria_checkpoint_interval                 | 30                  |\n| aria_checkpoint_log_activity             | 1048576             |\n| aria_force_start_after_recovery_failures | 0                   |\n| aria_group_commit                        | none                |\n| aria_group_commit_interval               | 0                   |\n| aria_log_file_size                       | 1073741824          |\n| aria_log_purge_type                      | immediate           |\n| aria_max_sort_file_size                  | 9223372036853727232 |\n| aria_page_checksum                       | ON                  |\n| aria_pagecache_age_threshold             | 300                 |\n| aria_pagecache_buffer_size               | 134217728           |\n| aria_pagecache_division_limit            | 100                 |\n| aria_recover                             | NORMAL              |\n| aria_repair_threads                      | 1                   |\n| aria_sort_buffer_size                    | 134217728           |\n| aria_stats_method                        | nulls_unequal       |\n| aria_sync_log_dir                        | NEWFILE             |\n| aria_used_for_temp_tables                | ON                  |\n+------------------------------------------+---------------------+\n\nURL: https://mariadb.com/kb/en/extended-show/','','https://mariadb.com/kb/en/extended-show/'),
(365,'SHOW CHARACTER SET',26,'Syntax\n------\n\nSHOW CHARACTER SET\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nThe SHOW CHARACTER SET statement shows all available character sets. The LIKE\nclause, if present on its own, indicates which character set names to match.\nThe WHERE and LIKE clauses can be given to select rows using more general\nconditions, as discussed in Extended SHOW.\n\nThe same information can be queried from the Information Schema CHARACTER_SETS\ntable.\n\nSee Setting Character Sets and Collations for details on specifying the\ncharacter set at the server, database, table and column levels.\n\nExamples\n--------\n\nSHOW CHARACTER SET LIKE \'latin%\';\n+---------+-----------------------------+-------------------+--------+\n| Charset | Description                 | Default collation | Maxlen |\n+---------+-----------------------------+-------------------+--------+\n| latin1  | cp1252 West European        | latin1_swedish_ci |      1 |\n| latin2  | ISO 8859-2 Central European | latin2_general_ci |      1 |\n| latin5  | ISO 8859-9 Turkish          | latin5_turkish_ci |      1 |\n| latin7  | ISO 8859-13 Baltic          | latin7_general_ci |      1 |\n+---------+-----------------------------+-------------------+--------+\n\nSHOW CHARACTER SET WHERE Maxlen LIKE \'2\';\n+---------+---------------------------+-------------------+--------+\n| Charset | Description               | Default collation | Maxlen |\n+---------+---------------------------+-------------------+--------+\n| big5    | Big5 Traditional Chinese  | big5_chinese_ci   |      2 |\n| sjis    | Shift-JIS Japanese        | sjis_japanese_ci  |      2 |\n| euckr   | EUC-KR Korean             | euckr_korean_ci   |      2 |\n| gb2312  | GB2312 Simplified Chinese | gb2312_chinese_ci |      2 |\n| gbk     | GBK Simplified Chinese    | gbk_chinese_ci    |      2 |\n| ucs2    | UCS-2 Unicode             | ucs2_general_ci   |      2 |\n| cp932   | SJIS for Windows Japanese | cp932_japanese_ci |      2 |\n+---------+---------------------------+-------------------+--------+\n\nURL: https://mariadb.com/kb/en/show-character-set/','','https://mariadb.com/kb/en/show-character-set/'),
(362,'SHOW AUTHORS',26,'Syntax\n------\n\nSHOW AUTHORS\n\nDescription\n-----------\n\nThe SHOW AUTHORS statement displays information about the people who work on\nMariaDB. For each author, it displays Name, Location, and Comment values. All\ncolumns are encoded as latin1.\n\nThese include:\n\n* First the active people in MariaDB are listed.\n* Then the active people in MySQL.\n* Last the people that have contributed to MariaDB/MySQL in the past.\n\nThe order is somewhat related to importance of the contribution given to the\nMariaDB project, but this is not 100% accurate. There is still room for\nimprovement and debate...\n\nExample\n-------\n\nSHOW AUTHORS\\G\n*************************** 1. row ***************************\n  Name: Michael (Monty) Widenius\nLocation: Tusby, Finland\n Comment: Lead developer and main author\n*************************** 2. row ***************************\n  Name: Sergei Golubchik\nLocation: Kerpen, Germany\n Comment: Architect, Full-text search, precision math, plugin framework,\nmerges etc\n*************************** 3. row ***************************\n  Name: Igor Babaev\nLocation: Bellevue, USA\n Comment: Optimizer, keycache, core work\n*************************** 4. row ***************************\n  Name: Sergey Petrunia\nLocation: St. Petersburg, Russia\n Comment: Optimizer\n*************************** 5. row ***************************\n  Name: Oleksandr Byelkin\nLocation: Lugansk, Ukraine\n Comment: Query Cache (4.0), Subqueries (4.1), Views (5.0)\n*************************** 6. row ***************************\n  Name: Timour Katchaounov\nLocation: Sofia , Bulgaria\n Comment: Optimizer\n*************************** 7. row ***************************\n  Name: Kristian Nielsen\nLocation: Copenhagen, Denmark\n Comment: Replication, Async client prototocol, General buildbot stuff\n*************************** 8. row ***************************\n  Name: Alexander (Bar) Barkov\nLocation: Izhevsk, Russia\n Comment: Unicode and character sets\n*************************** 9. row ***************************\n  Name: Alexey Botchkov (Holyfoot)\nLocation: Izhevsk, Russia\n Comment: GIS extensions, embedded server, precision math\n*************************** 10. row ***************************\n  Name: Daniel Bartholomew\nLocation: Raleigh, USA\n Comment: MariaDB documentation, Buildbot, releases\n*************************** 11. row ***************************\n  Name: Colin Charles\nLocation: Selangor, Malesia\n Comment: MariaDB documentation, talks at a LOT of conferences\n*************************** 12. row ***************************\n  Name: Sergey Vojtovich\nLocation: Izhevsk, Russia\n Comment: initial implementation of plugin architecture, maintained native\nstorage engines (MyISAM, MEMORY, ARCHIVE, etc), rewrite of table cache\n*************************** 13. row ***************************\n  Name: Vladislav Vaintroub\nLocation: Mannheim, Germany\n Comment: MariaDB Java connector, new thread pool, Windows optimizations\n*************************** 14. row ***************************\n  Name: Elena Stepanova\nLocation: Sankt Petersburg, Russia\n Comment: QA, test cases\n*************************** 15. row ***************************\n  Name: Georg Richter\nLocation: Heidelberg, Germany\n Comment: New LGPL C connector, PHP connector\n*************************** 16. row ***************************\n  Name: Jan Lindström\nLocation: Ylämylly, Finland\n Comment: Working on InnoDB\n*************************** 17. row ***************************\n  Name: Lixun Peng\nLocation: Hangzhou, China\n Comment: Multi Source replication\n*************************** 18. row ***************************\n  Name: Olivier Bertrand\nLocation: Paris, France\n Comment: CONNECT storage engine\n*************************** 19. row ***************************\n  Name: Kentoku Shiba\nLocation: Tokyo, Japan\n Comment: Spider storage engine, metadata_lock_info Information schema\n*************************** 20. row ***************************\n  Name: Percona\nLocation: CA, USA\n Comment: XtraDB, microslow patches, extensions to slow log\n*************************** 21. row ***************************\n  Name: Vicentiu Ciorbaru\nLocation: Bucharest, Romania\n Comment: Roles\n*************************** 22. row ***************************\n  Name: Sudheera Palihakkara\nLocation: \n Comment: PCRE Regular Expressions\n*************************** 23. row ***************************\n  Name: Pavel Ivanov\nLocation: USA\n Comment: Some patches and bug fixes\n*************************** 24. row ***************************\n  Name: Konstantin Osipov\nLocation: Moscow, Russia\n Comment: Prepared statements (4.1), Cursors (5.0), GET_LOCK (10.0)\n*************************** 25. row ***************************\n  Name: Ian Gilfillan\nLocation: South Africa\n Comment: MariaDB documentation\n*************************** 26. row ***************************\n  Name: Federico Razolli\nLocation: Italy\n Comment: MariaDB documentation Italian translation\n*************************** 27. row ***************************\n  Name: Guilhem Bichot\nLocation: Bordeaux, France\n Comment: Replication (since 4.0)\n*************************** 28. row ***************************\n  Name: Andrei Elkin\nLocation: Espoo, Finland\n Comment: Replication\n*************************** 29. row ***************************\n  Name: Dmitri Lenev\nLocation: Moscow, Russia\n Comment: Time zones support (4.1), Triggers (5.0)\n*************************** 30. row ***************************\n  Name: Marc Alff\nLocation: Denver, CO, USA\n Comment: Signal, Resignal, Performance schema\n*************************** 31. row ***************************\n  Name: Mikael Ronström\nLocation: Stockholm, Sweden\n Comment: NDB Cluster, Partitioning, online alter table\n*************************** 32. row ***************************\n  Name: Ingo Strüwing\nLocation: Berlin, Germany\n Comment: Bug fixing in MyISAM, Merge tables etc\n*************************** 33. row ***************************\n  Name: Marko Mäkelä\nLocation: Helsinki, Finland\n Comment: InnoDB core developer\n...\n\nURL: https://mariadb.com/kb/en/show-authors/','','https://mariadb.com/kb/en/show-authors/'),
(366,'SHOW CLIENT_STATISTICS',26,'Syntax\n------\n\nSHOW CLIENT_STATISTICS\n\nDescription\n-----------\n\nThe SHOW CLIENT_STATISTICS statement is part of the User Statistics feature.\nIt was removed as a separate statement in MariaDB 10.1.1, but effectively\nreplaced by the generic SHOW information_schema_table statement. The\ninformation_schema.CLIENT_STATISTICS table holds statistics about client\nconnections.\n\nThe userstat system variable must be set to 1 to activate this feature. See\nthe User Statistics and information_schema.CLIENT_STATISTICS articles for more\ninformation.\n\nExample\n-------\n\nSHOW CLIENT_STATISTICS\\G\n*************************** 1. row ***************************\n        Client: localhost\n  Total_connections: 35\nConcurrent_connections: 0\n    Connected_time: 708\n      Busy_time: 2.5557979999999985\n       Cpu_time: 0.04123740000000002\n    Bytes_received: 3883\n      Bytes_sent: 21595\n Binlog_bytes_written: 0\n      Rows_read: 18\n      Rows_sent: 115\n     Rows_deleted: 0\n    Rows_inserted: 0\n     Rows_updated: 0\n   Select_commands: 70\n   Update_commands: 0\n    Other_commands: 0\n Commit_transactions: 1\n Rollback_transactions: 0\n  Denied_connections: 0\n   Lost_connections: 0\n    Access_denied: 0\n    Empty_queries: 35\n\nURL: https://mariadb.com/kb/en/show-client-statistics/','','https://mariadb.com/kb/en/show-client-statistics/'),
(367,'SHOW CONTRIBUTORS',26,'Syntax\n------\n\nSHOW CONTRIBUTORS\n\nDescription\n-----------\n\nThe SHOW CONTRIBUTORS statement displays information about the companies and\npeople who financially contribute to MariaDB. For each contributor, it\ndisplays Name, Location, and Comment values. All columns are encoded as latin1.\n\nIt displays all members and sponsors of the MariaDB Foundation as well as\nother financial contributors.\n\nExample\n-------\n\nSHOW CONTRIBUTORS;\n+---------------------+-------------------------------+------------------------\n------------------------------------+\n| Name                | Location                      | Comment               \n                  |\n+---------------------+-------------------------------+------------------------\n------------------------------------+\n| Alibaba Cloud       | https://www.alibabacloud.com/ | Platinum Sponsor of\nthe MariaDB Foundation                  |\n| Tencent Cloud       | https://cloud.tencent.com     | Platinum Sponsor of\nthe MariaDB Foundation                  |\n| Microsoft           | https://microsoft.com/        | Platinum Sponsor of\nthe MariaDB Foundation                  |\n| MariaDB Corporation | https://mariadb.com           | Founding member,\nPlatinum Sponsor of the MariaDB Foundation |\n| ServiceNow          | https://servicenow.com        | Platinum Sponsor of\nthe MariaDB Foundation                  |\n| Intel               | https://www.intel.com         | Platinum Sponsor of\nthe MariaDB Foundation                  |\n| SIT                 | https://sit.org               | Platinum Sponsor of\nthe MariaDB Foundation                  |\n| Visma               | https://visma.com             | Gold Sponsor of the\nMariaDB Foundation                      |\n| DBS                 | https://dbs.com               | Gold Sponsor of the\nMariaDB Foundation                      |\n| IBM                 | https://www.ibm.com           | Gold Sponsor of the\nMariaDB Foundation                      |\n| Automattic          | https://automattic.com        | Silver Sponsor of the\nMariaDB Foundation                    |\n| Percona             | https://www.percona.com/      | Sponsor of the MariaDB\nFoundation                           |\n| Galera Cluster      | https://galeracluster.com     | Sponsor of the MariaDB\nFoundation                           |\n| Google              | USA                           | Sponsoring encryption,\nparallel replication and GTID        |\n| Facebook            | USA                           | Sponsoring\nnon-blocking API, LIMIT ROWS EXAMINED etc        |\n| Ronald Bradford     | Brisbane, Australia           | EFF contribution for\nUC2006 Auction                         |\n| Sheeri Kritzer      | Boston, Mass. USA             | EFF contribution for\nUC2006 Auction                         |\n| Mark Shuttleworth   | London, UK.                   | EFF contribution for\nUC2006 Auction                         |\n+---------------------+-------------------------------+------------------------\n------------------------------------+\n\nURL: https://mariadb.com/kb/en/show-contributors/','','https://mariadb.com/kb/en/show-contributors/'),
(368,'SHOW CREATE DATABASE',26,'Syntax\n------\n\nSHOW CREATE {DATABASE | SCHEMA} db_name\n\nDescription\n-----------\n\nShows the CREATE DATABASE statement that creates the given database. SHOW\nCREATE SCHEMA is a synonym for SHOW CREATE DATABASE. SHOW CREATE DATABASE\nquotes database names according to the value of the sql_quote_show_create\nserver system variable.\n\nExamples\n--------\n\nSHOW CREATE DATABASE test;\n+----------+-----------------------------------------------------------------+\n| Database | Create Database                                                 |\n+----------+-----------------------------------------------------------------+\n| test     | CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET latin1 */ |\n+----------+-----------------------------------------------------------------+\n\nSHOW CREATE SCHEMA test;\n+----------+-----------------------------------------------------------------+\n| Database | Create Database                                                 |\n+----------+-----------------------------------------------------------------+\n| test     | CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET latin1 */ |\n+----------+-----------------------------------------------------------------+\n\nWith sql_quote_show_create off:\n\nSHOW CREATE DATABASE test;\n+----------+---------------------------------------------------------------+\n| Database | Create Database                                               |\n+----------+---------------------------------------------------------------+\n| test     | CREATE DATABASE test /*!40100 DEFAULT CHARACTER SET latin1 */ |\n+----------+---------------------------------------------------------------+\n\nWith a comment, from MariaDB 10.5:\n\nSHOW CREATE DATABASE p;\n+----------+-------------------------------------------------------------------\n------------------+\n| Database | Create Database                                                  \n         |\n+----------+-------------------------------------------------------------------\n------------------+\n| p        | CREATE DATABASE `p` /*!40100 DEFAULT CHARACTER SET latin1 */\nCOMMENT \'presentations\' |\n+----------+-------------------------------------------------------------------\n------------------+\n\nURL: https://mariadb.com/kb/en/show-create-database/','','https://mariadb.com/kb/en/show-create-database/'),
(369,'SHOW CREATE EVENT',26,'Syntax\n------\n\nSHOW CREATE EVENT event_name\n\nDescription\n-----------\n\nThis statement displays the CREATE EVENT statement needed to re-create a given\nevent, as well as the SQL_MODE that was used when the trigger has been created\nand the character set used by the connection. To find out which events are\npresent, use SHOW EVENTS.\n\nThe output of this statement is unreliably affected by the\nsql_quote_show_create server system variable - see\nhttp://bugs.mysql.com/bug.php?id=12719\n\nThe information_schema.EVENTS table provides similar, but more complete,\ninformation.\n\nExamples\n--------\n\nSHOW CREATE EVENT test.e_daily\\G\n*************************** 1. row ***************************\n       Event: e_daily\n      sql_mode:\n     time_zone: SYSTEM\n    Create Event: CREATE EVENT `e_daily`\n            ON SCHEDULE EVERY 1 DAY\n            STARTS CURRENT_TIMESTAMP + INTERVAL 6 HOUR\n            ON COMPLETION NOT PRESERVE\n            ENABLE\n            COMMENT \'Saves total number of sessions then\n                clears the table each day\'\n            DO BEGIN\n             INSERT INTO site_activity.totals (time, total)\n              SELECT CURRENT_TIMESTAMP, COUNT(*)\n              FROM site_activity.sessions;\n             DELETE FROM site_activity.sessions;\n            END\ncharacter_set_client: latin1\ncollation_connection: latin1_swedish_ci\n Database Collation: latin1_swedish_ci\n\nURL: https://mariadb.com/kb/en/show-create-event/','','https://mariadb.com/kb/en/show-create-event/'),
(370,'SHOW CREATE FUNCTION',26,'Syntax\n------\n\nSHOW CREATE FUNCTION func_name\n\nDescription\n-----------\n\nThis statement is similar to SHOW CREATE PROCEDURE but for stored functions.\n\nThe output of this statement is unreliably affected by the\nsql_quote_show_create server system variable - see\nhttp://bugs.mysql.com/bug.php?id=12719\n\nExample\n-------\n\nSHOW CREATE FUNCTION VatCents\\G\n*************************** 1. row ***************************\n      Function: VatCents\n      sql_mode:\n  Create Function: CREATE DEFINER=`root`@`localhost` FUNCTION\n`VatCents`(price DECIMAL(10,2)) RETURNS int(11)\n  DETERMINISTIC\nBEGIN\n DECLARE x INT;\n SET x = price * 114;\n RETURN x;\nEND\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\nURL: https://mariadb.com/kb/en/show-create-function/','','https://mariadb.com/kb/en/show-create-function/'),
(371,'SHOW CREATE PACKAGE',26,'MariaDB starting with 10.3.5\n----------------------------\nOracle-style packages were introduced in MariaDB 10.3.5.\n\nSyntax\n------\n\nSHOW CREATE PACKAGE  [ db_name . ] package_name\n\nDescription\n-----------\n\nThe SHOW CREATE PACKAGE statement can be used when Oracle SQL_MODE is set.\n\nShows the CREATE statement that creates the given package specification.\n\nExamples\n--------\n\nSHOW CREATE PACKAGE employee_tools\\G\n*************************** 1. row ***************************\n      Package: employee_tools\n      sql_mode:\nPIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ORACLE,NO_KEY_OPTIONS,NO_TABLE_OPTIONS\nNO_FIELD_OPTIONS,NO_AUTO_CREATE_USER\n   Create Package: CREATE DEFINER=\"root\"@\"localhost\" PACKAGE\n\"employee_tools\" AS\n FUNCTION getSalary(eid INT) RETURN DECIMAL(10,2);\n PROCEDURE raiseSalary(eid INT, amount DECIMAL(10,2));\n PROCEDURE raiseSalaryStd(eid INT);\n PROCEDURE hire(ename TEXT, esalary DECIMAL(10,2));\nEND\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\nURL: https://mariadb.com/kb/en/show-create-package/','','https://mariadb.com/kb/en/show-create-package/'),
(372,'SHOW CREATE PACKAGE BODY',26,'MariaDB starting with 10.3.5\n----------------------------\nOracle-style packages were introduced in MariaDB 10.3.5.\n\nSyntax\n------\n\nSHOW CREATE PACKAGE BODY  [ db_name . ] package_name\n\nDescription\n-----------\n\nThe SHOW CREATE PACKAGE BODY statement can be used when Oracle SQL_MODE is set.\n\nShows the CREATE statement that creates the given package body (i.e. the\nimplementation).\n\nExamples\n--------\n\nSHOW CREATE PACKAGE BODY employee_tools\\G\n*************************** 1. row ***************************\n    Package body: employee_tools\n      sql_mode:\nPIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ORACLE,NO_KEY_OPTIONS,NO_TABLE_OPTIONS\nNO_FIELD_OPTIONS,NO_AUTO_CREATE_USER\n Create Package Body: CREATE DEFINER=\"root\"@\"localhost\" PACKAGE BODY\n\"employee_tools\" AS\n\nstdRaiseAmount DECIMAL(10,2):=500;\n\nPROCEDURE log (eid INT, ecmnt TEXT) AS\n BEGIN\n  INSERT INTO employee_log (id, cmnt) VALUES (eid, ecmnt);\n END;\n\nPROCEDURE hire(ename TEXT, esalary DECIMAL(10,2)) AS\n  eid INT;\n BEGIN\n  INSERT INTO employee (name, salary) VALUES (ename, esalary);\n  eid:= last_insert_id();\n  log(eid, \'hire \' || ename);\n END;\n\nFUNCTION getSalary(eid INT) RETURN DECIMAL(10,2) AS\n  nSalary DECIMAL(10,2);\n BEGIN\n  SELECT salary INTO nSalary FROM employee WHERE id=eid;\n  log(eid, \'getSalary id=\' || eid || \' salary=\' || nSalary);\n  RETURN nSalary;\n END;\n\nPROCEDURE raiseSalary(eid INT, amount DECIMAL(10,2)) AS\n BEGIN\n  UPDATE employee SET salary=salary+amount WHERE id=eid;\n  log(eid, \'raiseSalary id=\' || eid || \' amount=\' || amount);\n END;\n\nPROCEDURE raiseSalaryStd(eid INT) AS\n BEGIN\n  raiseSalary(eid, stdRaiseAmount);\n  log(eid, \'raiseSalaryStd id=\' || eid);\n END;\n\nBEGIN  \n log(0, \'Session \' || connection_id() || \' \' || current_user || \' started\');\nEND\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\nURL: https://mariadb.com/kb/en/show-create-package-body/','','https://mariadb.com/kb/en/show-create-package-body/'),
(373,'SHOW CREATE PROCEDURE',26,'Syntax\n------\n\nSHOW CREATE PROCEDURE proc_name\n\nDescription\n-----------\n\nThis statement is a MariaDB extension. It returns the exact string that can be\nused to re-create the named stored procedure, as well as the SQL_MODE that was\nused when the trigger has been created and the character set used by the\nconnection.. A similar statement, SHOW CREATE FUNCTION, displays information\nabout stored functions.\n\nBoth statements require that you are the owner of the routine or have the\nSELECT privilege on the mysql.proc table. When neither is true, the statements\ndisplay NULL for the Create Procedure or Create Function field.\n\nWarning Users with SELECT privileges on mysql.proc or USAGE privileges on *.*\ncan view the text of routines, even when they do not have privileges for the\nfunction or procedure itself.\n\nThe output of these statements is unreliably affected by the\nsql_quote_show_create server system variable - see\nhttp://bugs.mysql.com/bug.php?id=12719\n\nExamples\n--------\n\nHere\'s a comparison of the SHOW CREATE PROCEDURE and SHOW CREATE FUNCTION\nstatements.\n\nSHOW CREATE PROCEDURE test.simpleproc\\G\n*************************** 1. row ***************************\n     Procedure: simpleproc\n      sql_mode:\n  Create Procedure: CREATE PROCEDURE `simpleproc`(OUT param1 INT)\n           BEGIN\n           SELECT COUNT(*) INTO param1 FROM t;\n           END\ncharacter_set_client: latin1\ncollation_connection: latin1_swedish_ci\n Database Collation: latin1_swedish_ci\n\nSHOW CREATE FUNCTION test.hello\\G\n*************************** 1. row ***************************\n      Function: hello\n      sql_mode:\n  Create Function: CREATE FUNCTION `hello`(s CHAR(20))\n           RETURNS CHAR(50)\n           RETURN CONCAT(\'Hello, \',s,\'!\')\ncharacter_set_client: latin1\ncollation_connection: latin1_swedish_ci\n Database Collation: latin1_swedish_ci\n\nWhen the user issuing the statement does not have privileges on the routine,\nattempting to CALL the procedure raises Error 1370.\n\nCALL test.prc1();\nError 1370 (42000): execute command denieed to user \'test_user\'@\'localhost\'\nfor routine \'test\'.\'prc1\'\n\nIf the user neither has privilege to the routine nor the SELECT privilege on\nmysql.proc table, it raises Error 1305, informing them that the procedure does\nnot exist.\n\nSHOW CREATE TABLES test.prc1\\G\nError 1305 (42000): PROCEDURE prc1 does not exist\n\nURL: https://mariadb.com/kb/en/show-create-procedure/','','https://mariadb.com/kb/en/show-create-procedure/'),
(374,'SHOW CREATE SEQUENCE',26,'Syntax\n------\n\nSHOW CREATE SEQUENCE sequence_name;\n\nDescription\n-----------\n\nShows the CREATE SEQUENCE statement that created the given sequence. The\nstatement requires the SELECT privilege for the table.\n\nExample\n-------\n\nCREATE SEQUENCE s1 START WITH 50;\nSHOW CREATE SEQUENCE s1\\G;\n*************************** 1. row ***************************\n   Table: s1\nCreate Table: CREATE SEQUENCE `s1` start with 50 minvalue 1 maxvalue\n9223372036854775806 \n increment by 1 cache 1000 nocycle ENGINE=InnoDB\n\nNotes\n-----\n\nIf you want to see the underlying table structure used for the SEQUENCE you\ncan use SHOW CREATE TABLE on the SEQUENCE. You can also use SELECT to read the\ncurrent recorded state of the SEQUENCE:\n\nSHOW CREATE TABLE s1\\G\n*************************** 1. row ***************************\n   Table: s1\nCreate Table: CREATE TABLE `s1` (\n `next_not_cached_value` bigint(21) NOT NULL,\n `minimum_value` bigint(21) NOT NULL,\n `maximum_value` bigint(21) NOT NULL,\n `start_value` bigint(21) NOT NULL COMMENT \'start value when sequences is\ncreated \n  or value if RESTART is used\',\n `increment` bigint(21) NOT NULL COMMENT \'increment value\',\n `cache_size` bigint(21) unsigned NOT NULL,\n `cycle_option` tinyint(1) unsigned NOT NULL COMMENT \'0 if no cycles are\nallowed, \n  1 if the sequence should begin a new cycle when maximum_value is passed\',\n `cycle_count` bigint(21) NOT NULL COMMENT \'How many cycles have been done\'\n) ENGINE=InnoDB SEQUENCE=1\n\nSELECT * FROM s1\\G\n*************************** 1. row ***************************\nnext_not_cached_value: 50\n    minimum_value: 1\n    maximum_value: 9223372036854775806\n     start_value: 50\n      increment: 1\n     cache_size: 1000\n    cycle_option: 0\n     cycle_count: 0\n\nURL: https://mariadb.com/kb/en/show-create-sequence/','','https://mariadb.com/kb/en/show-create-sequence/'),
(375,'SHOW CREATE TRIGGER',26,'Syntax\n------\n\nSHOW CREATE TRIGGER trigger_name\n\nDescription\n-----------\n\nThis statement shows a CREATE TRIGGER statement that creates the given\ntrigger, as well as the SQL_MODE that was used when the trigger has been\ncreated and the character set used by the connection.\n\nThe TRIGGER privilege is required on the table the trigger is defined for to\nexecute this statement.\n\nThe output of this statement is unreliably affected by the\nsql_quote_show_create server system variable - see\nhttp://bugs.mysql.com/bug.php?id=12719\n\nExamples\n--------\n\nSHOW CREATE TRIGGER example\\G\n*************************** 1. row ***************************\n       Trigger: example\n       sql_mode:\nONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,STRICT_ALL_TABLES\n,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO\n\nENGINE_SUBSTITUTION\nSQL Original Statement: CREATE DEFINER=`root`@`localhost` TRIGGER example\nBEFORE\n INSERT ON t FOR EACH ROW\nBEGIN\n    SET NEW.c = NEW.c * 2;\nEND\n character_set_client: cp850\n collation_connection: cp850_general_ci\n Database Collation: utf8_general_ci\n Created: 2016-09-29 13:53:34.35\n\nMariaDB starting with 10.2.3\n----------------------------\nThe Created column was added in MySQL 5.7 and MariaDB 10.2.3 as part of\nintroducing multiple trigger events per action.\n\nURL: https://mariadb.com/kb/en/show-create-trigger/','','https://mariadb.com/kb/en/show-create-trigger/'),
(376,'SHOW CREATE VIEW',26,'Syntax\n------\n\nSHOW CREATE VIEW view_name\n\nDescription\n-----------\n\nThis statement shows a CREATE VIEW statement that creates the given view, as\nwell as the character set used by the connection when the view was created.\nThis statement also works with views.\n\nSHOW CREATE VIEW quotes table, column and stored function names according to\nthe value of the sql_quote_show_create server system variable.\n\nExamples\n--------\n\nSHOW CREATE VIEW example\\G\n*************************** 1. row ***************************\n        View: example\n    Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL\nSECURITY DEFINER VIEW `example` AS (select `t`.`id` AS `id`,`t`.`s` AS `s` from\n`t`)\ncharacter_set_client: cp850\ncollation_connection: cp850_general_ci\n\nWith sql_quote_show_create off:\n\nSHOW CREATE VIEW example\\G\n*************************** 1. row ***************************\n        View: example\n    Create View: CREATE ALGORITHM=UNDEFINED DEFINER=root@localhost SQL\nSECU\nRITY DEFINER VIEW example AS (select t.id AS id,t.s AS s from t)\ncharacter_set_client: cp850\ncollation_connection: cp850_general_ci\n\nGrants\n------\n\nTo be able to see a view, you need to have the SHOW VIEW and the SELECT\nprivilege on the view:\n\nGRANT SHOW VIEW,SELECT ON test_database.test_view TO \'test\'@\'localhost\';\n\nURL: https://mariadb.com/kb/en/show-create-view/','','https://mariadb.com/kb/en/show-create-view/'),
(377,'SHOW DATABASES',26,'Syntax\n------\n\nSHOW {DATABASES | SCHEMAS}\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nSHOW DATABASES lists the databases on the MariaDB server host. SHOW SCHEMAS is\na synonym for SHOW DATABASES. The LIKE clause, if present on its own,\nindicates which database names to match. The WHERE and LIKE clauses can be\ngiven to select rows using more general conditions, as discussed in Extended\nSHOW.\n\nYou see only those databases for which you have some kind of privilege, unless\nyou have the global SHOW DATABASES privilege. You can also get this list using\nthe mariadb-show command.\n\nIf the server was started with the --skip-show-database option, you cannot use\nthis statement at all unless you have the SHOW DATABASES privilege.\n\nThe list of results returned by SHOW DATABASES is based on directories in the\ndata directory, which is how MariaDB implements databases. It\'s possible that\noutput includes directories that do not correspond to actual databases.\n\nThe Information Schema SCHEMATA table also contains database information.\n\nExamples\n--------\n\nSHOW DATABASES;\n+--------------------+\n| Database           |\n+--------------------+\n| information_schema |\n| mysql              |\n| performance_schema |\n| test               |\n+--------------------+\n\nSHOW DATABASES LIKE \'m%\';\n+---------------+\n| Database (m%) |\n+---------------+\n| mysql         |\n+---------------+\n\nURL: https://mariadb.com/kb/en/show-databases/','','https://mariadb.com/kb/en/show-databases/'),
(380,'SHOW ENGINES',26,'Syntax\n------\n\nSHOW [STORAGE] ENGINES\n\nDescription\n-----------\n\nSHOW ENGINES displays status information about the server\'s storage engines.\nThis is particularly useful for checking whether a storage engine is\nsupported, or to see what the default engine is. SHOW TABLE TYPES is a\ndeprecated synonym.\n\nThe information_schema.ENGINES table provides the same information.\n\nSince storage engines are plugins, different information about them is also\nshown in the information_schema.PLUGINS table and by the SHOW PLUGINS\nstatement.\n\nNote that both MySQL\'s InnoDB and Percona\'s XtraDB replacement are labeled as\nInnoDB. However, if XtraDB is in use, it will be specified in the COMMENT\nfield. See XtraDB and InnoDB. The same applies to FederatedX.\n\nThe output consists of the following columns:\n\n* Engine indicates the engine\'s name.\n* Support indicates whether the engine is installed, and whether it is the\ndefault engine for the current session.\n* Comment is a brief description.\n* Transactions, XA and Savepoints indicate whether transactions, XA\ntransactions and transaction savepoints are supported by the engine.\n\nExamples\n--------\n\nSHOW ENGINES\\G\n*************************** 1. row ***************************\n   Engine: InnoDB\n  Support: DEFAULT\n  Comment: Supports transactions, row-level locking, and foreign keys\nTransactions: YES\n     XA: YES\n Savepoints: YES\n*************************** 2. row ***************************\n   Engine: CSV\n  Support: YES\n  Comment: CSV storage engine\nTransactions: NO\n     XA: NO\n Savepoints: NO\n*************************** 3. row ***************************\n   Engine: MyISAM\n  Support: YES\n  Comment: MyISAM storage engine\nTransactions: NO\n     XA: NO\n Savepoints: NO\n*************************** 4. row ***************************\n   Engine: BLACKHOLE\n  Support: YES\n  Comment: /dev/null storage engine (anything you write to it disappears)\nTransactions: NO\n     XA: NO\n Savepoints: NO\n*************************** 5. row ***************************\n   Engine: FEDERATED\n  Support: YES\n  Comment: FederatedX pluggable storage engine\nTransactions: YES\n     XA: NO\n Savepoints: YES\n*************************** 6. row ***************************\n   Engine: MRG_MyISAM\n  Support: YES\n  Comment: Collection of identical MyISAM tables\nTransactions: NO\n     XA: NO\n Savepoints: NO\n*************************** 7. row ***************************\n   Engine: ARCHIVE\n  Support: YES\n  Comment: Archive storage engine\nTransactions: NO\n     XA: NO\n Savepoints: NO\n*************************** 8. row ***************************\n   Engine: MEMORY\n  Support: YES\n  Comment: Hash based, stored in memory, useful for temporary tables\nTransactions: NO\n     XA: NO\n Savepoints: NO\n*************************** 9. row ***************************\n   Engine: PERFORMANCE_SCHEMA\n  Support: YES\n  Comment: Performance Schema\nTransactions: NO\n     XA: NO\n Savepoints: NO\n*************************** 10. row ***************************\n   Engine: Aria\n  Support: YES\n  Comment: Crash-safe tables with MyISAM heritage\nTransactions: NO\n     XA: NO\n Savepoints: NO\n10 rows in set (0.00 sec)\n\nURL: https://mariadb.com/kb/en/show-engines/','','https://mariadb.com/kb/en/show-engines/'),
(378,'SHOW ENGINE',26,'Syntax\n------\n\nSHOW ENGINE engine_name {STATUS | MUTEX}\n\nDescription\n-----------\n\nSHOW ENGINE displays operational information about a storage engine. The\nfollowing statements currently are supported:\n\nSHOW ENGINE INNODB STATUS\nSHOW ENGINE INNODB MUTEX\nSHOW ENGINE PERFORMANCE_SCHEMA STATUS\nSHOW ENGINE ROCKSDB STATUS\n\nIf the Sphinx Storage Engine is installed, the following is also supported:\n\nSHOW ENGINE SPHINX STATUS\n\nSee SHOW ENGINE SPHINX STATUS.\n\nOlder (and now removed) synonyms were SHOW INNODB STATUS for SHOW ENGINE\nINNODB STATUS and SHOW MUTEX STATUS for SHOW ENGINE INNODB MUTEX.\n\nSHOW ENGINE INNODB STATUS\n-------------------------\n\nSHOW ENGINE INNODB STATUS displays extensive information from the standard\nInnoDB Monitor about the state of the InnoDB storage engine. See SHOW ENGINE\nINNODB STATUS for more.\n\nSHOW ENGINE INNODB MUTEX\n------------------------\n\nSHOW ENGINE INNODB MUTEX displays InnoDB mutex statistics.\n\nThe statement displays the following output fields:\n\n* Type: Always InnoDB.\n* Name: The source file where the mutex is implemented, and the line number\n in the file where the mutex is created. The line number is dependent on the\nMariaDB version.\n* Status: This field displays the following values if UNIV_DEBUG was defined\nat compilation time (for example, in include/univ.h in the InnoDB part of the\nsource tree). Only the os_waits value is displayed if UNIV_DEBUG was not\ndefined. Without UNIV_DEBUG, the information on which the output is based is\ninsufficient to distinguish regular mutexes and mutexes that protect\n rw-locks (which allow multiple readers or a single writer). Consequently, the\n output may appear to contain multiple rows for the same mutex.\ncount indicates how many times the mutex was requested.\nspin_waits indicates how many times the spinlock had to run.\nspin_rounds indicates the number of spinlock rounds. (spin_rounds divided by\n spin_waits provides the average round count.)\nos_waits indicates the number of operating system waits. This occurs when\n the spinlock did not work (the mutex was not locked during the spinlock and\n it was necessary to yield to the operating system and wait).\nos_yields indicates the number of times a the thread trying to lock a mutex\n gave up its timeslice and yielded to the operating system (on the\n presumption that allowing other threads to run will free the mutex so that\n it can be locked).\nos_wait_times indicates the amount of time (in ms) spent in operating system\n waits, if the timed_mutexes system variable is 1 (ON). If timed_mutexes is 0\n (OFF), timing is disabled, so os_wait_times is 0. timed_mutexes is off by\n default.\n\nInformation from this statement can be used to diagnose system problems. For\nexample, large values of spin_waits and spin_rounds may indicate scalability\nproblems.\n\nThe information_schema.INNODB_MUTEXES table provides similar information.\n\nSHOW ENGINE PERFORMANCE_SCHEMA STATUS\n-------------------------------------\n\nThis statement shows how much memory is used for performance_schema tables and\ninternal buffers.\n\nThe output contains the following fields:\n\n* Type: Always performance_schema.\n* Name: The name of a table, the name of an internal buffer, or the\nperformance_schema word, followed by a dot and an attribute. Internal buffers\nnames are enclosed by parenthesis. performance_schema means that the attribute\nrefers to the whole database (it is a total). \n* Status: The value for the attribute.\n\nThe following attributes are shown, in this order, for all tables:\n\n* row_size: The memory used for an individual record. This value will never\nchange.\n* row_count: The number of rows in the table or buffer. For some tables, this\nvalue depends on a server system variable.\n* memory: For tables and performance_schema, this is the result of row_size *\nrow_count.\n\nFor internal buffers, the attributes are:\n\n* count\n* size\n\nSHOW ENGINE ROCKSDB STATUS\n--------------------------\n\nSee also MyRocks Performance Troubleshooting\n\nURL: https://mariadb.com/kb/en/show-engine/','','https://mariadb.com/kb/en/show-engine/'),
(381,'SHOW ERRORS',26,'Syntax\n------\n\nSHOW ERRORS [LIMIT [offset,] row_count]\nSHOW ERRORS [LIMIT row_count OFFSET offset]\nSHOW COUNT(*) ERRORS\n\nDescription\n-----------\n\nThis statement is similar to SHOW WARNINGS, except that instead of displaying\nerrors, warnings, and notes, it displays only errors.\n\nThe LIMIT clause has the same syntax as for the SELECT statement.\n\nThe SHOW COUNT(*) ERRORS statement displays the number of errors. You can also\nretrieve this number from the error_count variable.\n\nSHOW COUNT(*) ERRORS;\nSELECT @@error_count;\n\nThe value of error_count might be greater than the number of messages\ndisplayed by SHOW WARNINGS if the max_error_count system variable is set so\nlow that not all messages are stored.\n\nFor a list of MariaDB error codes, see MariaDB Error Codes.\n\nExamples\n--------\n\nSELECT f();\nERROR 1305 (42000): FUNCTION f does not exist\n\nSHOW COUNT(*) ERRORS;\n+-----------------------+\n| @@session.error_count |\n+-----------------------+\n|                     1 |\n+-----------------------+\n\nSHOW ERRORS;\n+-------+------+---------------------------+\n| Level | Code | Message                   |\n+-------+------+---------------------------+\n| Error | 1305 | FUNCTION f does not exist |\n+-------+------+---------------------------+\n\nURL: https://mariadb.com/kb/en/show-errors/','','https://mariadb.com/kb/en/show-errors/'),
(379,'SHOW ENGINE INNODB STATUS',26,'SHOW ENGINE INNODB STATUS is a specific form of the SHOW ENGINE statement that\ndisplays the InnoDB Monitor output, which is extensive InnoDB information\nwhich can be useful in diagnosing problems.\n\nThe following sections are displayed\n\n* Status: Shows the timestamp, monitor name and the number of seconds, or the\nelapsed time between the current time and the time the InnoDB Monitor output\nwas last displayed. The per-second averages are based upon this time.\n* BACKGROUND THREAD: srv_master_thread lines show work performed by the main\nbackground thread.\n* SEMAPHORES: Threads waiting for a semaphore and stats on how the number of\ntimes threads have needed a spin or a wait on a mutex or rw-lock semaphore. If\nthis number of threads is large, there may be I/O or contention issues.\nReducing the size of the innodb_thread_concurrency system variable may help if\ncontention is related to thread scheduling. Spin rounds per wait shows the\nnumber of spinlock rounds per OS wait for a mutex. \n* LATEST FOREIGN KEY ERROR: Only shown if there has been a foreign key\nconstraint error, it displays the failed statement and information about the\nconstraint and the related tables.\n* LATEST DETECTED DEADLOCK: Only shown if there has been a deadlock, it\ndisplays the transactions involved in the deadlock and the statements being\nexecuted, held and required locked and the transaction rolled back to.\n* TRANSACTIONS: The output of this section can help identify lock contention,\nas well as reasons for the deadlocks.\n* FILE I/O: InnoDB thread information as well as pending I/O operations and\nI/O performance statistics.\n* INSERT BUFFER AND ADAPTIVE HASH INDEX: InnoDB insert buffer (old name for\nthe change buffer) and adaptive hash index status information, including the\nnumber of each type of operation performed, and adaptive hash index\nperformance.\n* LOG: InnoDB log information, including current log sequence number, how far\nthe log has been flushed to disk, the position at which InnoDB last took a\ncheckpoint, pending writes and write performance statistics.\n* BUFFER POOL AND MEMORY: Information on buffer pool pages read and written,\nwhich allows you to see the number of data file I/O operations performed by\nyour queries. See InnoDB Buffer Pool for more. Similar information is also\navailable from the INFORMATION_SCHEMA.INNODB_BUFFER_POOL_STATS table.\n* ROW OPERATIONS:Information about the main thread, including the number and\nperformance rate for each type of row operation.\n\nIf the innodb_status_output_locks system variable is set to 1, extended lock\ninformation will be displayed.\n\nExample output:\n\n=====================================\n2019-09-06 12:44:13 0x7f93cc236700 INNODB MONITOR OUTPUT\n=====================================\nPer second averages calculated from the last 4 seconds\n-----------------\nBACKGROUND THREAD\n-----------------\nsrv_master_thread loops: 2 srv_active, 0 srv_shutdown, 83698 srv_idle\nsrv_master_thread log flush and writes: 83682\n----------\nSEMAPHORES\n----------\nOS WAIT ARRAY INFO: reservation count 15\nOS WAIT ARRAY INFO: signal count 8\nRW-shared spins 0, rounds 20, OS waits 7\nRW-excl spins 0, rounds 0, OS waits 0\nRW-sx spins 0, rounds 0, OS waits 0\nSpin rounds per wait: 20.00 RW-shared, 0.00 RW-excl, 0.00 RW-sx\n------------\nTRANSACTIONS\n------------\nTrx id counter 236\nPurge done for trx\'s n:o < 236 undo n:o < 0 state: running\nHistory list length 22\nLIST OF TRANSACTIONS FOR EACH SESSION:\n---TRANSACTION 421747401994584, not started\n0 lock struct(s), heap size 1136, 0 row lock(s)\n---TRANSACTION 421747401990328, not started\n0 lock struct(s), heap size 1136, 0 row lock(s)\n--------\nFILE I/O\n--------\nI/O thread 0 state: waiting for completed aio requests (insert buffer thread)\nI/O thread 1 state: waiting for completed aio requests (log thread)\nI/O thread 2 state: waiting for completed aio requests (read thread)\nI/O thread 3 state: waiting for completed aio requests (read thread)\nI/O thread 4 state: waiting for completed aio requests (read thread)\nI/O thread 5 state: waiting for completed aio requests (read thread)\nI/O thread 6 state: waiting for completed aio requests (write thread)\nI/O thread 7 state: waiting for completed aio requests (write thread)\nI/O thread 8 state: waiting for completed aio requests (write thread)\nI/O thread 9 state: waiting for completed aio requests (write thread)\nPending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,\n ibuf aio reads:, log i/o\'s:, sync i/o\'s:\nPending flushes (fsync) log: 0; buffer pool: 0\n286 OS file reads, 171 OS file writes, 22 OS fsyncs\n0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s\n-------------------------------------\nINSERT BUFFER AND ADAPTIVE HASH INDEX\n-------------------------------------\nIbuf: size 1, free list len 0, seg size 2, 0 merges\nmerged operations:\n insert 0, delete mark 0, delete 0\ndiscarded operations:\n insert 0, delete mark 0, delete 0\nHash table size 34679, node heap has 0 buffer(s)\nHash table size 34679, node heap has 0 buffer(s)\nHash table size 34679, node heap has 0 buffer(s)\nHash table size 34679, node heap has 0 buffer(s)\nHash table size 34679, node heap has 0 buffer(s)\nHash table size 34679, node heap has 0 buffer(s)\nHash table size 34679, node heap has 0 buffer(s)\nHash table size 34679, node heap has 0 buffer(s)\n0.00 hash searches/s, 0.00 non-hash searches/s\n---\nLOG\n---\nLog sequence number 445926\nLog flushed up to   445926\nPages flushed up to 445926\nLast checkpoint at  445917\n0 pending log flushes, 0 pending chkp writes\n18 log i/o\'s done, 0.00 log i/o\'s/second\n----------------------\nBUFFER POOL AND MEMORY\n----------------------\nTotal large memory allocated 167772160\nDictionary memory allocated 50768\nBuffer pool size   8012\nFree buffers       7611\nDatabase pages     401\nOld database pages 0\nModified db pages  0\nPercent of dirty pages(LRU & free pages): 0.000\nMax dirty pages percent: 75.000\nPending reads 0\nPending writes: LRU 0, flush list 0, single page 0\nPages made young 0, not young 0\n0.00 youngs/s, 0.00 non-youngs/s\nPages read 264, created 137, written 156\n0.00 reads/s, 0.00 creates/s, 0.00 writes/s\nNo buffer pool page gets since the last printout\nPages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead\n0.00/s\nLRU len: 401, unzip_LRU len: 0\nI/O sum[0]:cur[0], unzip sum[0]:cur[0]\n--------------\nROW OPERATIONS\n--------------\n0 queries inside InnoDB, 0 queries in queue\n0 read views open inside InnoDB\nProcess ID=4267, Main thread ID=140272021272320, state: sleeping\nNumber of rows inserted 1, updated 0, deleted 0, read 1\n0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s\nNumber of system rows inserted 0, updated 0, deleted 0, read 0\n0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s\n----------------------------\nEND OF INNODB MONITOR OUTPUT\n============================\n\nURL: https://mariadb.com/kb/en/show-engine-innodb-status/','','https://mariadb.com/kb/en/show-engine-innodb-status/'),
(382,'SHOW EVENTS',26,'Syntax\n------\n\nSHOW EVENTS [{FROM | IN} schema_name]\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nShows information about Event Manager events (created with CREATE EVENT).\nRequires the EVENT privilege. Without any arguments, SHOW EVENTS lists all of\nthe events in the current schema:\n\nSELECT CURRENT_USER(), SCHEMA();\n+----------------+----------+\n| CURRENT_USER() | SCHEMA() |\n+----------------+----------+\n| jon@ghidora    | myschema |\n+----------------+----------+\n\nSHOW EVENTS\\G\n*************************** 1. row ***************************\n         Db: myschema\n        Name: e_daily\n      Definer: jon@ghidora\n     Time zone: SYSTEM\n        Type: RECURRING\n     Execute at: NULL\n   Interval value: 10\n   Interval field: SECOND\n       Starts: 2006-02-09 10:41:23\n        Ends: NULL\n       Status: ENABLED\n     Originator: 0\ncharacter_set_client: latin1\ncollation_connection: latin1_swedish_ci\n Database Collation: latin1_swedish_ci\n\nTo see the event action, use SHOW CREATE EVENT instead, or look at the\ninformation_schema.EVENTS table.\n\nTo see events for a specific schema, use the FROM clause. For example, to see\nevents for the test schema, use the following statement:\n\nSHOW EVENTS FROM test;\n\nThe LIKE clause, if present, indicates which event names to match. The WHERE\nclause can be given to select rows using more general conditions, as discussed\nin Extended Show.\n\nURL: https://mariadb.com/kb/en/show-events/','','https://mariadb.com/kb/en/show-events/'),
(383,'SHOW FUNCTION STATUS',26,'Syntax\n------\n\nSHOW FUNCTION STATUS\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nThis statement is similar to SHOW PROCEDURE STATUS but for stored functions.\n\nThe LIKE clause, if present on its own, indicates which function names to\nmatch.\n\nThe WHERE and LIKE clauses can be given to select rows using more general\nconditions, as discussed in Extended SHOW.\n\nThe information_schema.ROUTINES table contains more detailed information.\n\nExamples\n--------\n\nShowing all stored functions:\n\nSHOW FUNCTION STATUS\\G\n*************************** 1. row ***************************\n         Db: test\n        Name: VatCents\n        Type: FUNCTION\n      Definer: root@localhost\n      Modified: 2013-06-01 12:40:31\n      Created: 2013-06-01 12:40:31\n   Security_type: DEFINER\n      Comment:\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\nStored functions whose name starts with \'V\':\n\nSHOW FUNCTION STATUS LIKE \'V%\' \\G\n*************************** 1. row ***************************\n         Db: test\n        Name: VatCents\n        Type: FUNCTION\n      Definer: root@localhost\n      Modified: 2013-06-01 12:40:31\n      Created: 2013-06-01 12:40:31\n   Security_type: DEFINER\n      Comment:\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\nStored functions with a security type of \'DEFINER\':\n\nSHOW FUNCTION STATUS WHERE Security_type LIKE \'DEFINER\' \\G\n*************************** 1. row ***************************\n         Db: test\n        Name: VatCents\n        Type: FUNCTION\n      Definer: root@localhost\n      Modified: 2013-06-01 12:40:31\n      Created: 2013-06-01 12:40:31\n   Security_type: DEFINER\n      Comment:\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\nURL: https://mariadb.com/kb/en/show-function-status/','','https://mariadb.com/kb/en/show-function-status/'),
(384,'SHOW LOCALES',26,'SHOW LOCALES was introduced as part of the Information Schema plugin extension.\n\nSHOW LOCALES is used to return locales information as part of the Locales\nplugin. While the information_schema.LOCALES table has 8 columns, the SHOW\nLOCALES statement will only display 4 of them:\n\nExample\n-------\n\nSHOW LOCALES;\n+-----+-------+-------------------------------------+------------------------+\n| Id  | Name  | Description                         | Error_Message_Language |\n+-----+-------+-------------------------------------+------------------------+\n|   0 | en_US | English - United States             | english                |\n|   1 | en_GB | English - United Kingdom            | english                |\n|   2 | ja_JP | Japanese - Japan                    | japanese               |\n|   3 | sv_SE | Swedish - Sweden                    | swedish                |\n...\n\nURL: https://mariadb.com/kb/en/show-locales/','','https://mariadb.com/kb/en/show-locales/'),
(385,'SHOW OPEN TABLES',26,'Syntax\n------\n\nSHOW OPEN TABLES [FROM db_name]\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nSHOW OPEN TABLES lists the non-TEMPORARY tables that are currently open in the\ntable cache. See http://dev.mysql.com/doc/refman/5.1/en/table-cache.html.\n\nThe FROM and LIKE clauses may be used.\n\nThe FROM clause, if present, restricts the tables shown to those present in\nthe db_name database.\n\nThe LIKE clause, if present on its own, indicates which table names to match.\nThe WHERE and LIKE clauses can be given to select rows using more general\nconditions, as discussed in Extended SHOW.\n\nThe following information is returned:\n\n+---------------------------+------------------------------------------------+\n| Column                    | Description                                    |\n+---------------------------+------------------------------------------------+\n| Database                  | Database name.                                 |\n+---------------------------+------------------------------------------------+\n| Name                      | Table name.                                    |\n+---------------------------+------------------------------------------------+\n| In_use                    | Number of  table instances being used.         |\n+---------------------------+------------------------------------------------+\n| Name_locked               | 1 if the table is name-locked, e.g. if it is   |\n|                           | being dropped or renamed, otherwise 0.         |\n+---------------------------+------------------------------------------------+\n\nBefore MariaDB 5.5, each use of, for example, LOCK TABLE ... WRITE would\nincrement In_use for that table. With the implementation of the metadata\nlocking improvements in MariaDB 5.5, LOCK TABLE... WRITE acquires a strong MDL\nlock, and concurrent connections will wait on this MDL lock, so any subsequent\nLOCK TABLE... WRITE will not increment In_use.\n\nExample\n-------\n\nSHOW OPEN TABLES;\n+----------+---------------------------+--------+-------------+\n| Database | Table                     | In_use | Name_locked |\n+----------+---------------------------+--------+-------------+\n...\n| test     | xjson                     |      0 |           0 |\n| test     | jauthor                   |      0 |           0 |\n| test     | locks                     |      1 |           0 |\n...\n+----------+---------------------------+--------+-------------+\n\nURL: https://mariadb.com/kb/en/show-open-tables/','','https://mariadb.com/kb/en/show-open-tables/'),
(386,'SHOW PACKAGE BODY STATUS',26,'MariaDB starting with 10.3.5\n----------------------------\nOracle-style packages were introduced in MariaDB 10.3.5.\n\nSyntax\n------\n\nSHOW PACKAGE BODY STATUS\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nThe SHOW PACKAGE BODY STATUS statement returns characteristics of stored\npackage bodies (implementations), such as the database, name, type, creator,\ncreation and modification dates, and character set information. A similar\nstatement, SHOW PACKAGE STATUS, displays information about stored package\nspecifications.\n\nThe LIKE clause, if present, indicates which package names to match. The WHERE\nand LIKE clauses can be given to select rows using more general conditions, as\ndiscussed in Extended SHOW.\n\nThe ROUTINES table in the INFORMATION_SCHEMA database contains more detailed\ninformation.\n\nExamples\n--------\n\nSHOW PACKAGE BODY STATUS LIKE \'pkg1\'\\G\n*************************** 1. row ***************************\n         Db: test\n        Name: pkg1\n        Type: PACKAGE BODY\n      Definer: root@localhost\n      Modified: 2018-02-27 14:44:14\n      Created: 2018-02-27 14:44:14\n   Security_type: DEFINER\n      Comment: This is my first package body\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\nURL: https://mariadb.com/kb/en/show-package-body-status/','','https://mariadb.com/kb/en/show-package-body-status/'),
(387,'SHOW PACKAGE STATUS',26,'MariaDB starting with 10.3.5\n----------------------------\nOracle-style packages were introduced in MariaDB 10.3.5.\n\nSyntax\n------\n\nSHOW PACKAGE STATUS\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nThe SHOW PACKAGE STATUS statement returns characteristics of stored package\nspecifications, such as the database, name, type, creator, creation and\nmodification dates, and character set information. A similar statement, SHOW\nPACKAGE BODY STATUS, displays information about stored package bodies (i.e.\nimplementations).\n\nThe LIKE clause, if present, indicates which package names to match. The WHERE\nand LIKE clauses can be given to select rows using more general conditions, as\ndiscussed in Extended SHOW.\n\nThe ROUTINES table in the INFORMATION_SCHEMA database contains more detailed\ninformation.\n\nExamples\n--------\n\nSHOW PACKAGE STATUS LIKE \'pkg1\'\\G\n*************************** 1. row ***************************\n         Db: test\n        Name: pkg1\n        Type: PACKAGE\n      Definer: root@localhost\n      Modified: 2018-02-27 14:38:15\n      Created: 2018-02-27 14:38:15\n   Security_type: DEFINER\n      Comment: This is my first package\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\nURL: https://mariadb.com/kb/en/show-package-status/','','https://mariadb.com/kb/en/show-package-status/'),
(389,'SHOW PROCEDURE CODE',26,'Syntax\n------\n\nSHOW PROCEDURE CODE proc_name\n\nDescription\n-----------\n\nThis statement is a MariaDB extension that is available only for servers that\nhave been built with debugging support. It displays a representation of the\ninternal implementation of the named stored procedure. A similar statement,\nSHOW FUNCTION CODE, displays information about stored functions.\n\nBoth statements require that you be the owner of the routine or have SELECT\naccess to the mysql.proc table.\n\nIf the named routine is available, each statement produces a result set. Each\nrow in the result set corresponds to one \"instruction\" in the routine. The\nfirst column is Pos, which is an ordinal number beginning with 0. The second\ncolumn is Instruction, which contains an SQL statement (usually changed from\nthe original source), or a directive which has meaning only to the\nstored-routine handler.\n\nExamples\n--------\n\nDELIMITER //\n\nCREATE PROCEDURE p1 ()\n BEGIN\n  DECLARE fanta INT DEFAULT 55;\n  DROP TABLE t2;\n  LOOP\n   INSERT INTO t3 VALUES (fanta);\n   END LOOP;\n END//\nQuery OK, 0 rows affected (0.00 sec)\n\nSHOW PROCEDURE CODE p1//\n+-----+----------------------------------------+\n| Pos | Instruction                            |\n+-----+----------------------------------------+\n|   0 | set fanta@0 55                         |\n|   1 | stmt 9 \"DROP TABLE t2\"                 |\n|   2 | stmt 5 \"INSERT INTO t3 VALUES (fanta)\" |\n|   3 | jump 2                                 |\n+-----+----------------------------------------+\n\nURL: https://mariadb.com/kb/en/show-procedure-code/','','https://mariadb.com/kb/en/show-procedure-code/'),
(390,'SHOW PROCEDURE STATUS',26,'Syntax\n------\n\nSHOW PROCEDURE STATUS\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nThis statement is a MariaDB extension. It returns characteristics of a stored\nprocedure, such as the database, name, type, creator, creation and\nmodification dates, and character set information. A similar statement, SHOW\nFUNCTION STATUS, displays information about stored functions.\n\nThe LIKE clause, if present, indicates which procedure or function names to\nmatch. The WHERE and LIKE clauses can be given to select rows using more\ngeneral conditions, as discussed in Extended SHOW.\n\nThe ROUTINES table in the INFORMATION_SCHEMA database contains more detailed\ninformation.\n\nExamples\n--------\n\nSHOW PROCEDURE STATUS LIKE \'p1\'\\G\n*************************** 1. row ***************************\n         Db: test\n        Name: p1\n        Type: PROCEDURE\n      Definer: root@localhost\n      Modified: 2010-08-23 13:23:03\n      Created: 2010-08-23 13:23:03\n   Security_type: DEFINER\n      Comment:\ncharacter_set_client: latin1\ncollation_connection: latin1_swedish_ci\n Database Collation: latin1_swedish_ci\n\nURL: https://mariadb.com/kb/en/show-procedure-status/','','https://mariadb.com/kb/en/show-procedure-status/'),
(388,'SHOW PRIVILEGES',26,'Syntax\n------\n\nSHOW PRIVILEGES\n\nDescription\n-----------\n\nSHOW PRIVILEGES shows the list of system privileges that the MariaDB server\nsupports. The exact list of privileges depends on the version of your server.\n\nNote that before MariaDB 10.3.23, MariaDB 10.4.13 and MariaDB 10.5.2 , the\nDelete history privilege displays as Delete versioning rows (MDEV-20382).\n\nExample\n-------\n\nFrom MariaDB 10.5.9\n\nSHOW PRIVILEGES;\n+--------------------------+---------------------------------------+-----------\n--------------------------------------------------------+\n| Privilege                | Context                               | Comment  \n                            |\n+--------------------------+---------------------------------------+-----------\n--------------------------------------------------------+\n| Alter                    | Tables                                | To alter\nthe table                                                 |\n| Alter routine            | Functions,Procedures                  | To alter\nor drop stored functions/procedures                       |\n| Create                   | Databases,Tables,Indexes              | To create\nnew databases and tables                                 |\n| Create routine           | Databases                             | To use\nCREATE FUNCTION/PROCEDURE                                   |\n| Create temporary tables  | Databases                             | To use\nCREATE TEMPORARY TABLE                                      |\n| Create view              | Tables                                | To create\nnew views                                                |\n| Create user              | Server Admin                          | To create\nnew users                                                |\n| Delete                   | Tables                                | To delete\nexisting rows                                            |\n| Delete history           | Tables                                | To delete\nversioning table historical rows                         |\n| Drop                     | Databases,Tables                      | To drop\ndatabases, tables, and views                               |\n| Event                    | Server Admin                          | To\ncreate, alter, drop and execute events                          |\n| Execute                  | Functions,Procedures                  | To\nexecute stored routines                                         |\n| File                     | File access on server                 | To read\nand write files on the server                              |\n| Grant option             | Databases,Tables,Functions,Procedures | To give\nto other users those privileges you possess                |\n| Index                    | Tables                                | To create\nor drop indexes                                          |\n| Insert                   | Tables                                | To insert\ndata into tables                                         |\n| Lock tables              | Databases                             | To use\nLOCK TABLES (together with SELECT privilege)                |\n| Process                  | Server Admin                          | To view\nthe plain text of currently executing queries              |\n| Proxy                    | Server Admin                          | To make\nproxy user possible                                        |\n| References               | Databases,Tables                      | To have\nreferences on tables                                       |\n| Reload                   | Server Admin                          | To reload\nor refresh tables, logs and privileges                   |\n| Binlog admin             | Server                                | To purge\nbinary logs                                               |\n| Binlog monitor           | Server                                | To use\nSHOW BINLOG STATUS and SHOW BINARY LOG                      |\n| Binlog replay            | Server                                | To use\nBINLOG (generated by mariadb-binlog)                        |\n| Replication master admin | Server                                | To\nmonitor connected slaves                                        |\n| Replication slave admin  | Server                                | To\nstart/stop slave and apply binlog events                        |\n| Slave monitor            | Server                                | To use\nSHOW SLAVE STATUS and SHOW RELAYLOG EVENTS                  |\n| Replication slave        | Server Admin                          | To read\nbinary log events from the master                          |\n| Select                   | Tables                                | To\nretrieve rows from table                                        |\n| Show databases           | Server Admin                          | To see\nall databases with SHOW DATABASES                           |\n| Show view                | Tables                                | To see\nviews with SHOW CREATE VIEW                                 |\n| Shutdown                 | Server Admin                          | To shut\ndown the server                                            |\n| Super                    | Server Admin                          | To use\nKILL thread, SET GLOBAL, CHANGE MASTER, etc.                |\n| Trigger                  | Tables                                | To use\ntriggers                                                    |\n| Create tablespace        | Server Admin                          | To\ncreate/alter/drop tablespaces                                   |\n| Update                   | Tables                                | To update\nexisting rows                                            |\n| Set user                 | Server                                | To create\nviews and stored routines with a different definer       |\n| Federated admin          | Server                                | To\nexecute the CREATE SERVER, ALTER SERVER, DROP SERVER statements |\n| Connection admin         | Server                                | To bypass\nconnection limits and kill other users\' connections      |\n| Read_only admin          | Server                                | To\nperform write operations even if @@read_only=ON                 |\n| Usage                    | Server Admin                          | No\nprivileges - allow connect only                                 |\n+--------------------------+---------------------------------------+-----------\n--------------------------------------------------------+\n41 rows in set (0.000 sec)\n\nURL: https://mariadb.com/kb/en/show-privileges/','','https://mariadb.com/kb/en/show-privileges/'),
(391,'SHOW PROCESSLIST',26,'Syntax\n------\n\nSHOW [FULL] PROCESSLIST\n\nDescription\n-----------\n\nSHOW PROCESSLIST shows you which threads are running. You can also get this\ninformation from the information_schema.PROCESSLIST table or the mariadb-admin\nprocesslist command. If you have the PROCESS privilege, you can see all\nthreads. Otherwise, you can see only your own threads (that is, threads\nassociated with the MariaDB account that you are using). If you do not use the\nFULL keyword, only the first 100 characters of each statement are shown in the\nInfo field.\n\nThe columns shown in SHOW PROCESSLIST are:\n\n+---------------------+------------------------------------------------------+\n| Name                | Description                                          |\n+---------------------+------------------------------------------------------+\n| ID                  | The client\'s process ID.                             |\n+---------------------+------------------------------------------------------+\n| USER                | The username associated with the process.            |\n+---------------------+------------------------------------------------------+\n| HOST                | The host the client is connected to.                 |\n+---------------------+------------------------------------------------------+\n| DB                  | The default database of the process (NULL if no      |\n|                     | default).                                            |\n+---------------------+------------------------------------------------------+\n| COMMAND             | The command type. See Thread Command Values.         |\n+---------------------+------------------------------------------------------+\n| TIME                | The amount of time, in seconds, the process has      |\n|                     | been in its current state. For a replica SQL thread  |\n|                     | before MariaDB 10.1, this is the time in seconds     |\n|                     | between the last replicated event\'s timestamp and    |\n|                     | the replica machine\'s real time.                     |\n+---------------------+------------------------------------------------------+\n| STATE               | See Thread States.                                   |\n+---------------------+------------------------------------------------------+\n| INFO                | The statement being executed.                        |\n+---------------------+------------------------------------------------------+\n| PROGRESS            | The total progress of the process (0-100%) (see      |\n|                     | Progress Reporting).                                 |\n+---------------------+------------------------------------------------------+\n\nSee TIME_MS column in information_schema.PROCESSLIST for differences in the\nTIME column between MariaDB and MySQL.\n\nThe information_schema.PROCESSLIST table contains the following additional\ncolumns:\n\n+---------------------+------------------------------------------------------+\n| Name                | Description                                          |\n+---------------------+------------------------------------------------------+\n| TIME_MS             | The amount of time, in milliseconds, the process     |\n|                     | has been in its current state.                       |\n+---------------------+------------------------------------------------------+\n| STAGE               | The stage the process is currently in.               |\n+---------------------+------------------------------------------------------+\n| MAX_STAGE           | The maximum number of stages.                        |\n+---------------------+------------------------------------------------------+\n| PROGRESS            | The progress of the process within the current       |\n|                     | stage (0-100%).                                      |\n+---------------------+------------------------------------------------------+\n| MEMORY_USED         | The amount of memory used by the process.            |\n+---------------------+------------------------------------------------------+\n| EXAMINED_ROWS       | The number of rows the process has examined.         |\n+---------------------+------------------------------------------------------+\n| QUERY_ID            | Query ID.                                            |\n+---------------------+------------------------------------------------------+\n\nNote that the PROGRESS field from the information schema, and the PROGRESS\nfield from SHOW PROCESSLIST display different results. SHOW PROCESSLIST shows\nthe total progress, while the information schema shows the progress for the\ncurrent stage only.\n\nThreads can be killed using their thread_id or their query_id, with the KILL\nstatement.\n\nSince queries on this table are locking, if the performance_schema is enabled,\nyou may want to query the THREADS table instead.\n\nExamples\n--------\n\nSHOW PROCESSLIST;\n+----+-----------------+-----------+------+---------+------+-------------------\n----+------------------+----------+\n| Id | User            | Host      | db   | Command | Time | State            \n  | Info             | Progress |\n+----+-----------------+-----------+------+---------+------+-------------------\n----+------------------+----------+\n|  2 | event_scheduler | localhost | NULL | Daemon  | 2693 | Waiting on empty\nqueue | NULL             |    0.000 |\n|  4 | root            | localhost | NULL | Query   |    0 | Table lock       \n  | SHOW PROCESSLIST |    0.000 |\n+----+-----------------+-----------+------+---------+------+-------------------\n----+------------------+----------+\n\nURL: https://mariadb.com/kb/en/show-processlist/','','https://mariadb.com/kb/en/show-processlist/'),
(392,'SHOW PROFILE',26,'Syntax\n------\n\nSHOW PROFILE [type [, type] ... ]\n  [FOR QUERY n]\n  [LIMIT row_count [OFFSET offset]]\n\ntype:\n  ALL\n | BLOCK IO\n | CONTEXT SWITCHES\n | CPU\n | IPC\n | MEMORY\n | PAGE FAULTS\n | SOURCE\n | SWAPS\n\nDescription\n-----------\n\nThe SHOW PROFILE and SHOW PROFILES statements display profiling information\nthat indicates resource usage for statements executed during the course of the\ncurrent session.\n\nProfiling is controlled by the profiling session variable, which has a default\nvalue of 0 (OFF). Profiling is enabled by setting profiling to 1 or ON:\n\nSET profiling = 1;\n\nSHOW PROFILES displays a list of the most recent statements sent to the\nmaster. The size of the list is controlled by the profiling_history_size\nsession variable, which has a default value of 15. The maximum value is 100.\nSetting the value to 0 has the practical effect of disabling profiling.\n\nAll statements are profiled except SHOW PROFILES and SHOW PROFILE, so you will\nfind neither of those statements in the profile list. Malformed statements are\nprofiled. For example, SHOW PROFILING is an illegal statement, and a syntax\nerror occurs if you try to execute it, but it will show up in the profiling\nlist.\n\nSHOW PROFILE displays detailed information about a single statement. Without\nthe FOR QUERY n clause, the output pertains to the most recently executed\nstatement. If FOR QUERY n is included, SHOW PROFILE displays information for\nstatement n. The values of n correspond to the Query_ID values displayed by\nSHOW PROFILES.\n\nThe LIMIT row_count clause may be given to limit the output to row_count rows.\nIf LIMIT is given, OFFSET offset may be added to begin the output offset rows\ninto the full set of rows.\n\nBy default, SHOW PROFILE displays Status and Duration columns. The Status\nvalues are like the State values displayed by SHOW PROCESSLIST, although there\nmight be some minor differences in interpretation for the two statements for\nsome status values (see\nhttp://dev.mysql.com/doc/refman/5.6/en/thread-information.html).\n\nOptional type values may be specified to display specific additional types of\ninformation:\n\n* ALL displays all information\n* BLOCK IO displays counts for block input and output operations\n* CONTEXT SWITCHES displays counts for voluntary and involuntary context\nswitches\n* CPU displays user and system CPU usage times\n* IPC displays counts for messages sent and received\n* MEMORY is not currently implemented\n* PAGE FAULTS displays counts for major and minor page faults\n* SOURCE displays the names of functions from the source code, together with\nthe name and line number of the file in which the function occurs\n* SWAPS displays swap counts\n\nProfiling is enabled per session. When a session ends, its profiling\ninformation is lost.\n\nThe information_schema.PROFILING table contains similar information.\n\nExamples\n--------\n\nSELECT @@profiling;\n+-------------+\n| @@profiling |\n+-------------+\n|           0 |\n+-------------+\n\nSET profiling = 1;\n\nUSE test;\n\nDROP TABLE IF EXISTS t1;\n\nCREATE TABLE T1 (id INT);\n\nSHOW PROFILES;\n+----------+------------+--------------------------+\n| Query_ID | Duration   | Query                    |\n+----------+------------+--------------------------+\n|        1 | 0.00009200 | SELECT DATABASE()        |\n|        2 | 0.00023800 | show databases           |\n|        3 | 0.00018900 | show tables              |\n|        4 | 0.00014700 | DROP TABLE IF EXISTS t1  |\n|        5 | 0.24476900 | CREATE TABLE T1 (id INT) |\n+----------+------------+--------------------------+\n\nSHOW PROFILE;\n+----------------------+----------+\n| Status               | Duration |\n+----------------------+----------+\n| starting             | 0.000042 |\n| checking permissions | 0.000044 |\n| creating table       | 0.244645 |\n| After create         | 0.000013 |\n| query end            | 0.000003 |\n| freeing items        | 0.000016 |\n| logging slow query   | 0.000003 |\n| cleaning up          | 0.000003 |\n+----------------------+----------+\n\nSHOW PROFILE FOR QUERY 4;\n+--------------------+----------+\n| Status             | Duration |\n+--------------------+----------+\n| starting           | 0.000126 |\n| query end          | 0.000004 |\n| freeing items      | 0.000012 |\n| logging slow query | 0.000003 |\n| cleaning up        | 0.000002 |\n+--------------------+----------+\n\nSHOW PROFILE CPU FOR QUERY 5;\n+----------------------+----------+----------+------------+\n| Status               | Duration | CPU_user | CPU_system |\n+----------------------+----------+----------+------------+\n| starting             | 0.000042 | 0.000000 |   0.000000 |\n| checking permissions | 0.000044 | 0.000000 |   0.000000 |\n| creating table       | 0.244645 | 0.000000 |   0.000000 |\n| After create         | 0.000013 | 0.000000 |   0.000000 |\n| query end            | 0.000003 | 0.000000 |   0.000000 |\n| freeing items        | 0.000016 | 0.000000 |   0.000000 |\n| logging slow query   | 0.000003 | 0.000000 |   0.000000 |\n| cleaning up          | 0.000003 | 0.000000 |   0.000000 |\n+----------------------+----------+----------+------------+\n\nURL: https://mariadb.com/kb/en/show-profile/','','https://mariadb.com/kb/en/show-profile/'),
(395,'SHOW STATUS',26,'Syntax\n------\n\nSHOW [GLOBAL | SESSION] STATUS\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nSHOW STATUS provides server status information. This information also can be\nobtained using the mariadb-admin extended-status command, or by querying the\nInformation Schema GLOBAL_STATUS and SESSION_STATUS tables. The LIKE clause,\nif present, indicates which variable names to match. The WHERE clause can be\ngiven to select rows using more general conditions.\n\nWith the GLOBAL modifier, SHOW STATUS displays the status values for all\nconnections to MariaDB. With SESSION, it displays the status values for the\ncurrent connection. If no modifier is present, the default is SESSION. LOCAL\nis a synonym for SESSION. If you see a lot of 0 values, the reason is probably\nthat you have used SHOW STATUS with a new connection instead of SHOW GLOBAL\nSTATUS.\n\nSome status variables have only a global value. For these, you get the same\nvalue for both GLOBAL and SESSION.\n\nSee Server Status Variables for a full list, scope and description of the\nvariables that can be viewed with SHOW STATUS.\n\nThe LIKE clause, if present on its own, indicates which variable name to match.\n\nThe WHERE and LIKE clauses can be given to select rows using more general\nconditions, as discussed in Extended SHOW.\n\nExamples\n--------\n\nSHOW GLOBAL STATUS;\n+--------------------------------------------------------------+---------------\n------------------------+\n| Variable_name                                                | Value        \n            |\n+--------------------------------------------------------------+---------------\n------------------------+\n| Aborted_clients                                              | 0            \n            |\n| Aborted_connects                                             | 0            \n            |\n| Access_denied_errors                                         | 0            \n            |\n| Acl_column_grants                                            | 0            \n            |\n| Acl_database_grants                                          | 2            \n            |\n| Acl_function_grants                                          | 0            \n            |\n| Acl_procedure_grants                                         | 0            \n            |\n| Acl_proxy_users                                              | 2            \n            |\n| Acl_role_grants                                              | 0            \n            |\n| Acl_roles                                                    | 0            \n            |\n| Acl_table_grants                                             | 0            \n            |\n| Acl_users                                                    | 6            \n            |\n| Aria_pagecache_blocks_not_flushed                            | 0            \n            |\n| Aria_pagecache_blocks_unused                                 | 15706        \n            |\n...\n| wsrep_local_index                                            |\n18446744073709551615                   |\n| wsrep_provider_name                                          |              \n            |\n| wsrep_provider_vendor                                        |              \n            |\n| wsrep_provider_version                                       |              \n            |\n| wsrep_ready                                                  | OFF          \n            |\n| wsrep_thread_count                                           | 0            \n            |\n+--------------------------------------------------------------+---------------\n------------------------+\n516 rows in set (0.00 sec)\n\nExample of filtered output:\n\nSHOW STATUS LIKE \'Key%\';\n+------------------------+--------+\n| Variable_name          | Value  |\n+------------------------+--------+\n| Key_blocks_not_flushed | 0      |\n| Key_blocks_unused      | 107163 |\n| Key_blocks_used        | 0      |\n| Key_blocks_warm        | 0      |\n| Key_read_requests      | 0      |\n| Key_reads              | 0      |\n| Key_write_requests     | 0      |\n| Key_writes             | 0      |\n+------------------------+--------+\n8 rows in set (0.00 sec)\n\nURL: https://mariadb.com/kb/en/show-status/','','https://mariadb.com/kb/en/show-status/'),
(397,'SHOW TABLES',26,'Syntax\n------\n\nSHOW [FULL] TABLES [FROM db_name]\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nSHOW TABLES lists the tables (until MariaDB 11.2.0, only non-TEMPORARY tables\nare shown), sequences and views in a given database.\n\nThe LIKE clause, if present on its own, indicates which table names to match.\nThe WHERE and LIKE clauses can be given to select rows using more general\nconditions, as discussed in Extended SHOW. For example, when searching for\ntables in the test database, the column name for use in the WHERE and LIKE\nclauses will be Tables_in_test\n\nThe FULL modifier is supported such that SHOW FULL TABLES displays a second\noutput column. Values for the second column, Table_type, are BASE TABLE for a\ntable, VIEW for a view and SEQUENCE for a sequence.\n\nYou can also get this information using:\n\nmariadb-show db_name\n\nSee mariadb-show for more details.\n\nIf you have no privileges for a base table or view, it does not show up in the\noutput from SHOW TABLES or mariadb-show db_name.\n\nThe information_schema.TABLES table, as well as the SHOW TABLE STATUS\nstatement, provide extended information about tables.\n\nExamples\n--------\n\nSHOW TABLES;\n+----------------------+\n| Tables_in_test       |\n+----------------------+\n| animal_count         |\n| animals              |\n| are_the_mooses_loose |\n| aria_test2           |\n| t1                   |\n| view1                |\n+----------------------+\n\nShowing the tables beginning with a only.\n\nSHOW TABLES WHERE Tables_in_test LIKE \'a%\';\n+----------------------+\n| Tables_in_test       |\n+----------------------+\n| animal_count         |\n| animals              |\n| are_the_mooses_loose |\n| aria_test2           |\n+----------------------+\n\nShowing tables and table types:\n\nSHOW FULL TABLES;\n+----------------+------------+\n| Tables_in_test | Table_type |\n+----------------+------------+\n| s1             | SEQUENCE   |\n| student        | BASE TABLE |\n| v1             | VIEW       |\n+----------------+------------+\n\nShowing temporary tables: <= MariaDB 11.1\n\nCREATE TABLE t (t int(11));\nCREATE TEMPORARY TABLE t (t int(11));\nCREATE TEMPORARY TABLE te (t int(11));\n\nSHOW TABLES;\n+----------------+\n| Tables_in_test |\n+----------------+\n| t              |\n+----------------+\n\nFrom MariaDB 11.2.0:\n\nCREATE TABLE t (t int(11));\nCREATE TEMPORARY TABLE t (t int(11));\nCREATE TEMPORARY TABLE te (t int(11));\n\nSHOW TABLES;\n+----------------+\n| Tables_in_test |\n+----------------+\n| te             |\n| t              |\n| t              |\n+----------------+\n\nURL: https://mariadb.com/kb/en/show-tables/','','https://mariadb.com/kb/en/show-tables/'),
(396,'SHOW TABLE STATUS',26,'Syntax\n------\n\nSHOW TABLE STATUS [{FROM | IN} db_name]\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nSHOW TABLE STATUS works like SHOW TABLES, but provides more extensive\ninformation about each table (until MariaDB 11.2.0, only non-TEMPORARY tables\nare shown).\n\nThe LIKE clause, if present on its own, indicates which table names to match.\nThe WHERE and LIKE clauses can be given to select rows using more general\nconditions, as discussed in Extended SHOW.\n\nThe following information is returned:\n\n+---------------------------+------------------------------------------------+\n| Column                    | Description                                    |\n+---------------------------+------------------------------------------------+\n| Name                      | Table name.                                    |\n+---------------------------+------------------------------------------------+\n| Engine                    | Table storage engine.                          |\n+---------------------------+------------------------------------------------+\n| Version                   | Version number from the table\'s .frm file.     |\n+---------------------------+------------------------------------------------+\n| Row_format                | Row format (see InnoDB, Aria and MyISAM row    |\n|                           | formats).                                      |\n+---------------------------+------------------------------------------------+\n| Rows                      | Number of rows in the table. Some engines,     |\n|                           | such as InnoDB may store an estimate.          |\n+---------------------------+------------------------------------------------+\n| Avg_row_length            | Average row length in the table.               |\n+---------------------------+------------------------------------------------+\n| Data_length               | For InnoDB, the index size, in pages,          |\n|                           | multiplied by the page size. For Aria and      |\n|                           | MyISAM, length of the data file, in bytes.     |\n|                           | For MEMORY, the approximate allocated memory.  |\n+---------------------------+------------------------------------------------+\n| Max_data_length           | Maximum length of the data file, ie the total  |\n|                           | number of bytes that could be stored in the    |\n|                           | table. Not used in InnoDB.                     |\n+---------------------------+------------------------------------------------+\n| Index_length              | Length of the index file.                      |\n+---------------------------+------------------------------------------------+\n| Data_free                 | Bytes allocated but unused. For InnoDB tables  |\n|                           | in a shared tablespace, the free space of the  |\n|                           | shared tablespace with small safety margin.    |\n|                           | An estimate in the case of partitioned tables  |\n|                           | - see the PARTITIONS table.                    |\n+---------------------------+------------------------------------------------+\n| Auto_increment            | Next AUTO_INCREMENT value.                     |\n+---------------------------+------------------------------------------------+\n| Create_time               | Time the table was created. Some engines just  |\n|                           | return the ctime information from the file     |\n|                           | system layer here, in that case the value is   |\n|                           | not necessarily the table creation time but    |\n|                           | rather the time the file system metadata for   |\n|                           | it had last changed.                           |\n+---------------------------+------------------------------------------------+\n| Update_time               | Time the table was last updated. On Windows,   |\n|                           | the timestamp is not updated on update, so     |\n|                           | MyISAM values will be inaccurate. In InnoDB,   |\n|                           | if shared tablespaces are used, will be NULL,  |\n|                           | while buffering can also delay the update, so  |\n|                           | the value will differ from the actual time of  |\n|                           | the last UPDATE, INSERT or DELETE.             |\n+---------------------------+------------------------------------------------+\n| Check_time                | Time the table was last checked. Not kept by   |\n|                           | all storage engines, in which case will be     |\n|                           | NULL.                                          |\n+---------------------------+------------------------------------------------+\n| Collation                 | Character set and collation.                   |\n+---------------------------+------------------------------------------------+\n| Checksum                  | Live checksum value, if any.                   |\n+---------------------------+------------------------------------------------+\n| Create_options            | Extra CREATE TABLE options.                    |\n+---------------------------+------------------------------------------------+\n| Comment                   | Table comment provided when MariaDB created    |\n|                           | the table.                                     |\n+---------------------------+------------------------------------------------+\n| Max_index_length          | Maximum index length (supported by MyISAM and  |\n|                           | Aria tables).                                  |\n+---------------------------+------------------------------------------------+\n| Temporary                 | Until MariaDB 11.2.0, placeholder to signal    |\n|                           | that a table is a temporary table and always   |\n|                           | \"N\", except \"Y\" for generated                  |\n|                           | information_schema tables and NULL for views.  |\n|                           | From MariaDB 11.2.0, will also be set to \"Y\"   |\n|                           | for local temporary tables.                    |\n+---------------------------+------------------------------------------------+\n\nSimilar information can be found in the information_schema.TABLES table as\nwell as by using mariadb-show:\n\nmariadb-show --status db_name\n\nViews\n-----\n\nFor views, all columns in SHOW TABLE STATUS are NULL except \'Name\' and\n\'Comment\'\n\nExample\n-------\n\nshow table status\\G\n*************************** 1. row ***************************\n     Name: bus_routes\n    Engine: InnoDB\n    Version: 10\n  Row_format: Dynamic\n     Rows: 5\n Avg_row_length: 3276\n  Data_length: 16384\nMax_data_length: 0\n Index_length: 0\n   Data_free: 0\n Auto_increment: NULL\n  Create_time: 2017-05-24 11:17:46\n  Update_time: NULL\n  Check_time: NULL\n   Collation: latin1_swedish_ci\n   Checksum: NULL\n Create_options: \n    Comment:\n\nURL: https://mariadb.com/kb/en/show-table-status/','','https://mariadb.com/kb/en/show-table-status/'),
(398,'SHOW TABLE_STATISTICS',26,'Syntax\n------\n\nSHOW TABLE_STATISTICS\n\nDescription\n-----------\n\nThe SHOW TABLE_STATISTICS statementis part of the User Statistics feature. It\nwas removed as a separate statement in MariaDB 10.1.1, but effectively\nreplaced by the generic SHOW information_schema_table statement. The\ninformation_schema.TABLE_STATISTICS table shows statistics on table usage\n\nThe userstat system variable must be set to 1 to activate this feature. See\nthe User Statistics and information_schema.TABLE_STATISTICS articles for more\ninformation.\n\nExample\n-------\n\nSHOW TABLE_STATISTICS\\G\n*************************** 1. row ***************************\n     Table_schema: mysql\n      Table_name: proxies_priv\n       Rows_read: 2\n     Rows_changed: 0\nRows_changed_x_#indexes: 0\n*************************** 2. row ***************************\n     Table_schema: test\n      Table_name: employees_example\n       Rows_read: 7\n     Rows_changed: 0\nRows_changed_x_#indexes: 0\n*************************** 3. row ***************************\n     Table_schema: mysql\n      Table_name: user\n       Rows_read: 16\n     Rows_changed: 0\nRows_changed_x_#indexes: 0\n*************************** 4. row ***************************\n     Table_schema: mysql\n      Table_name: db\n       Rows_read: 2\n     Rows_changed: 0\nRows_changed_x_#indexes: 0\n\nURL: https://mariadb.com/kb/en/show-table-statistics/','','https://mariadb.com/kb/en/show-table-statistics/'),
(399,'SHOW TRIGGERS',26,'Syntax\n------\n\nSHOW TRIGGERS [FROM db_name]\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nSHOW TRIGGERS lists the triggers currently defined for tables in a database\n(the default database unless a FROM clause is given). This statement requires\nthe TRIGGER privilege (prior to MySQL 5.1.22, it required the SUPER privilege).\n\nThe LIKE clause, if present on its own, indicates which table names to match\nand causes the statement to display triggers for those tables. The WHERE and\nLIKE clauses can be given to select rows using more general conditions, as\ndiscussed in Extended SHOW.\n\nSimilar information is stored in the information_schema.TRIGGERS table.\n\nMariaDB starting with 10.2.3\n----------------------------\nIf there are multiple triggers for the same action, then the triggers are\nshown in action order.\n\nExamples\n--------\n\nFor the trigger defined at Trigger Overview:\n\nSHOW triggers Like \'animals\' \\G\n*************************** 1. row ***************************\n      Trigger: the_mooses_are_loose\n       Event: INSERT\n       Table: animals\n     Statement: BEGIN\n IF NEW.name = \'Moose\' THEN\n UPDATE animal_count SET animal_count.animals = animal_count.animals+100;\n ELSE \n UPDATE animal_count SET animal_count.animals = animal_count.animals+1;\n END IF;\nEND\n       Timing: AFTER\n      Created: 2016-09-29 13:53:34.35\n      sql_mode:\n      Definer: root@localhost\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\nListing all triggers associated with a certain table:\n\nSHOW TRIGGERS FROM test WHERE `Table` = \'user\' \\G\n*************************** 1. row ***************************\n      Trigger: user_ai\n       Event: INSERT\n       Table: user\n     Statement: BEGIN END\n       Timing: AFTER\n      Created:  2016-09-29 13:53:34.35\n      sql_mode:\n      Definer: root@%\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\nSHOW triggers WHERE Event Like \'Insert\' \\G\n*************************** 1. row ***************************\n      Trigger: the_mooses_are_loose\n       Event: INSERT\n       Table: animals\n     Statement: BEGIN\n IF NEW.name = \'Moose\' THEN\n UPDATE animal_count SET animal_count.animals = animal_count.animals+100;\n ELSE \n UPDATE animal_count SET animal_count.animals = animal_count.animals+1;\n END IF;\nEND\n       Timing: AFTER\n      Created: 2016-09-29 13:53:34.35\n      sql_mode:\n      Definer: root@localhost\ncharacter_set_client: utf8\ncollation_connection: utf8_general_ci\n Database Collation: latin1_swedish_ci\n\n* character_set_client is the session value of the character_set_client system\nvariable when the trigger was created. \n* collation_connection is the session value of the collation_connection system\nvariable when the trigger was\n created. \n* Database Collation is the collation of the database \n with which the trigger is associated.\n\nThese columns were added in MariaDB/MySQL 5.1.21.\n\nOld triggers created before MySQL 5.7 and MariaDB 10.2.3 has NULL in the\nCreated column.\n\nURL: https://mariadb.com/kb/en/show-triggers/','','https://mariadb.com/kb/en/show-triggers/'),
(400,'SHOW USER_STATISTICS',26,'Syntax\n------\n\nSHOW USER_STATISTICS\n\nDescription\n-----------\n\nThe SHOW USER_STATISTICS statement is part of the User Statistics feature. It\nwas removed as a separate statement in MariaDB 10.1.1, but effectively\nreplaced by the generic SHOW information_schema_table statement. The\ninformation_schema.USER_STATISTICS table holds statistics about user activity.\nYou can use this table to find out such things as which user is causing the\nmost load and which users are being abusive. You can also use this table to\nmeasure how close to capacity the server may be.\n\nThe userstat system variable must be set to 1 to activate this feature. See\nthe User Statistics and information_schema.USER_STATISTICS table for more\ninformation.\n\nExample\n-------\n\nSHOW USER_STATISTICS\\G\n*************************** 1. row ***************************\n         User: root\n  Total_connections: 1\nConcurrent_connections: 0\n    Connected_time: 3297\n      Busy_time: 0.14113400000000006\n       Cpu_time: 0.017637000000000003\n    Bytes_received: 969\n      Bytes_sent: 22355\n Binlog_bytes_written: 0\n      Rows_read: 10\n      Rows_sent: 67\n     Rows_deleted: 0\n    Rows_inserted: 0\n     Rows_updated: 0\n   Select_commands: 7\n   Update_commands: 0\n    Other_commands: 0\n Commit_transactions: 1\n Rollback_transactions: 0\n  Denied_connections: 0\n   Lost_connections: 0\n    Access_denied: 0\n    Empty_queries: 7\n\nURL: https://mariadb.com/kb/en/show-user-statistics/','','https://mariadb.com/kb/en/show-user-statistics/'),
(401,'SHOW VARIABLES',26,'Syntax\n------\n\nSHOW [GLOBAL | SESSION] VARIABLES\n  [LIKE \'pattern\' | WHERE expr]\n\nDescription\n-----------\n\nSHOW VARIABLES shows the values of MariaDB system variables. This information\nalso can be obtained using the mariadb-admin variables command. The LIKE\nclause, if present, indicates which variable names to match. The WHERE clause\ncan be given to select rows using more general conditions.\n\nWith the GLOBAL modifier, SHOW VARIABLES displays the values that are used for\nnew connections to MariaDB. With SESSION, it displays the values that are in\neffect for the current connection. If no modifier is present, the default is\nSESSION. LOCAL is a synonym for SESSION. With a LIKE clause, the statement\ndisplays only rows for those variables with names that match the pattern. To\nobtain the row for a specific variable, use a LIKE clause as shown:\n\nSHOW VARIABLES LIKE \'maria_group_commit\';\nSHOW SESSION VARIABLES LIKE \'maria_group_commit\';\n\nTo get a list of variables whose name match a pattern, use the \"%\" wildcard\ncharacter in a LIKE clause:\n\nSHOW VARIABLES LIKE \'%maria%\';\nSHOW GLOBAL VARIABLES LIKE \'%maria%\';\n\nWildcard characters can be used in any position within the pattern to be\nmatched. Strictly speaking, because \"_\" is a wildcard that matches any single\ncharacter, you should escape it as \"\\_\" to match it literally. In practice,\nthis is rarely necessary.\n\nThe WHERE and LIKE clauses can be given to select rows using more general\nconditions, as discussed in Extended SHOW.\n\nSee SET for information on setting server system variables.\n\nSee Server System Variables for a list of all the variables that can be set.\n\nYou can also see the server variables by querying the Information Schema\nGLOBAL_VARIABLES and SESSION_VARIABLES tables.\n\nExamples\n--------\n\nSHOW VARIABLES LIKE \'aria%\';\n+------------------------------------------+---------------------+\n| Variable_name                            | Value               |\n+------------------------------------------+---------------------+\n| aria_block_size                          | 8192                |\n| aria_checkpoint_interval                 | 30                  |\n| aria_checkpoint_log_activity             | 1048576             |\n| aria_force_start_after_recovery_failures | 0                   |\n| aria_group_commit                        | none                |\n| aria_group_commit_interval               | 0                   |\n| aria_log_file_size                       | 1073741824          |\n| aria_log_purge_type                      | immediate           |\n| aria_max_sort_file_size                  | 9223372036853727232 |\n| aria_page_checksum                       | ON                  |\n| aria_pagecache_age_threshold             | 300                 |\n| aria_pagecache_buffer_size               | 134217728           |\n| aria_pagecache_division_limit            | 100                 |\n| aria_recover                             | NORMAL              |\n| aria_repair_threads                      | 1                   |\n| aria_sort_buffer_size                    | 134217728           |\n| aria_stats_method                        | nulls_unequal       |\n| aria_sync_log_dir                        | NEWFILE             |\n| aria_used_for_temp_tables                | ON                  |\n+------------------------------------------+---------------------+\n\nSELECT VARIABLE_NAME, SESSION_VALUE, GLOBAL_VALUE FROM\n INFORMATION_SCHEMA.SYSTEM_VARIABLES WHERE\n VARIABLE_NAME LIKE \'max_error_count\' OR\n VARIABLE_NAME LIKE \'innodb_sync_spin_loops\';\n+---------------------------+---------------+--------------+\n| VARIABLE_NAME             | SESSION_VALUE | GLOBAL_VALUE |\n+---------------------------+---------------+--------------+\n| MAX_ERROR_COUNT           | 64            | 64           |\n| INNODB_SYNC_SPIN_LOOPS    | NULL          | 30           |\n+---------------------------+---------------+--------------+\n\nSET GLOBAL max_error_count=128;\n\nSELECT VARIABLE_NAME, SESSION_VALUE, GLOBAL_VALUE FROM\n INFORMATION_SCHEMA.SYSTEM_VARIABLES WHERE\n VARIABLE_NAME LIKE \'max_error_count\' OR\n VARIABLE_NAME LIKE \'innodb_sync_spin_loops\';\n+---------------------------+---------------+--------------+\n| VARIABLE_NAME             | SESSION_VALUE | GLOBAL_VALUE |\n+---------------------------+---------------+--------------+\n| MAX_ERROR_COUNT           | 64            | 128          |\n| INNODB_SYNC_SPIN_LOOPS    | NULL          | 30           |\n+---------------------------+---------------+--------------+\n\nSET GLOBAL max_error_count=128;\n\nSHOW VARIABLES LIKE \'max_error_count\';\n+-----------------+-------+\n| Variable_name   | Value |\n+-----------------+-------+\n| max_error_count | 64    |\n+-----------------+-------+\n\nSHOW GLOBAL VARIABLES LIKE \'max_error_count\';\n+-----------------+-------+\n| Variable_name   | Value |\n+-----------------+-------+\n| max_error_count | 128   |\n+-----------------+-------+\n\nBecause the following variable only has a global scope, the global value is\nreturned even when specifying SESSION (in this case by default):\n\nSHOW VARIABLES LIKE \'innodb_sync_spin_loops\';\n+------------------------+-------+\n| Variable_name          | Value |\n+------------------------+-------+\n| innodb_sync_spin_loops | 30    |\n+------------------------+-------+\n\nURL: https://mariadb.com/kb/en/show-variables/','','https://mariadb.com/kb/en/show-variables/'),
(402,'SHOW WARNINGS',26,'Syntax\n------\n\nSHOW WARNINGS [LIMIT [offset,] row_count]\nSHOW ERRORS [LIMIT row_count OFFSET offset]\nSHOW COUNT(*) WARNINGS\n\nDescription\n-----------\n\nSHOW WARNINGS shows the error, warning, and note messages that resulted from\nthe last statement that generated messages in the current session. It shows\nnothing if the last statement used a table and generated no messages. (That\nis, a statement that uses a table but generates no messages clears the message\nlist.) Statements that do not use tables and do not generate messages have no\neffect on the message list.\n\nA note is different to a warning in that it only appears if the sql_notes\nvariable is set to 1 (the default), and is not converted to an error if strict\nmode is enabled.\n\nA related statement, SHOW ERRORS, shows only the errors.\n\nThe SHOW COUNT(*) WARNINGS statement displays the total number of errors,\nwarnings, and notes. You can also retrieve this number from the warning_count\nvariable:\n\nSHOW COUNT(*) WARNINGS;\nSELECT @@warning_count;\n\nThe value of warning_count might be greater than the number of messages\ndisplayed by SHOW WARNINGS if the max_error_count system variable is set so\nlow that not all messages are stored.\n\nThe LIMIT clause has the same syntax as for the SELECT statement.\n\nSHOW WARNINGS can be used after EXPLAIN EXTENDED to see how a query is\ninternally rewritten by MariaDB.\n\nIf the sql_notes server variable is set to 1, Notes are included in the output\nof SHOW WARNINGS; if it is set to 0, this statement will not show (or count)\nNotes.\n\nThe results of SHOW WARNINGS and SHOW COUNT(*) WARNINGS are directly sent to\nthe client. If you need to access those information in a stored program, you\ncan use the GET DIAGNOSTICS statement instead.\n\nFor a list of MariaDB error codes, see MariaDB Error Codes.\n\nThe mariadb client also has a number of options related to warnings. The \\W\ncommand will show warnings after every statement, while \\w will disable this.\nStarting the client with the --show-warnings option will show warnings after\nevery statement.\n\nMariaDB implements a stored routine error stack trace. SHOW WARNINGS can also\nbe used to show more information. See the example below.\n\nExamples\n--------\n\nSELECT 1/0;\n+------+\n| 1/0  |\n+------+\n| NULL |\n+------+\n\nSHOW COUNT(*) WARNINGS;\n+-------------------------+\n| @@session.warning_count |\n+-------------------------+\n|                       1 |\n+-------------------------+\n\nSHOW WARNINGS;\n+---------+------+---------------+\n| Level   | Code | Message       |\n+---------+------+---------------+\n| Warning | 1365 | Division by 0 |\n+---------+------+---------------+\n\nStack Trace\n-----------\n\nDisplaying a stack trace:\n\nDELIMITER $$\nCREATE OR REPLACE PROCEDURE p1()\n BEGIN\n  DECLARE c CURSOR FOR SELECT * FROM not_existing;\n  OPEN c;\n  CLOSE c;\n END;\n$$\nCREATE OR REPLACE PROCEDURE p2()\n BEGIN\n  CALL p1;\n END;\n$$\nDELIMITER ;\nCALL p2;\nERROR 1146 (42S02): Table \'test.not_existing\' doesn\'t exist\n\nSHOW WARNINGS;\n+-------+------+-----------------------------------------+\n| Level | Code | Message                                 |\n+-------+------+-----------------------------------------+\n| Error | 1146 | Table \'test.not_existing\' doesn\'t exist |\n| Note  | 4091 | At line 6 in test.p1                    |\n| Note  | 4091 | At line 4 in test.p2                    |\n+-------+------+-----------------------------------------+\n\nSHOW WARNINGS displays a stack trace, showing where the error actually\nhappened:\n\n* Line 4 in test.p1 is the OPEN command which actually raised the error\n* Line 3 in test.p2 is the CALL statement, calling p1 from p2.\n\nURL: https://mariadb.com/kb/en/show-warnings/','','https://mariadb.com/kb/en/show-warnings/'),
(403,'SHOW WSREP_MEMBERSHIP',26,'SHOW WSREP_MEMBERSHIP is part of the WSREP_INFO plugin.\n\nSyntax\n------\n\nSHOW WSREP_MEMBERSHIP\n\nDescription\n-----------\n\nThe SHOW WSREP_MEMBERSHIP statement returns Galera node cluster membership\ninformation. It returns the same information as found in the\ninformation_schema.WSREP_MEMBERSHIP table. Only users with the SUPER privilege\ncan access this information.\n\nExamples\n--------\n\nSHOW WSREP_MEMBERSHIP;\n+-------+--------------------------------------+----------+-----------------+\n| Index | Uuid                                 | Name     | Address         |\n+-------+--------------------------------------+----------+-----------------+\n|     0 | 19058073-8940-11e4-8570-16af7bf8fced | my_node1 | 10.0.2.15:16001 |\n|     1 | 19f2b0e0-8942-11e4-9cb8-b39e8ee0b5dd | my_node3 | 10.0.2.15:16003 |\n|     2 | d85e62db-8941-11e4-b1ef-4bc9980e476d | my_node2 | 10.0.2.15:16002 |\n+-------+--------------------------------------+----------+-----------------+\n\nURL: https://mariadb.com/kb/en/show-wsrep_membership/','','https://mariadb.com/kb/en/show-wsrep_membership/'),
(404,'SHOW WSREP_STATUS',26,'SHOW WSREP_STATUS is part of the WSREP_INFO plugin.\n\nSyntax\n------\n\nSHOW WSREP_STATUS\n\nDescription\n-----------\n\nThe SHOW WSREP_STATUS statement returns Galera node and cluster status\ninformation. It returns the same information as found in the\ninformation_schema.WSREP_STATUS table. Only users with the SUPER privilege can\naccess this information.\n\nExamples\n--------\n\nSHOW WSREP_STATUS;\n+------------+-------------+----------------+--------------+\n| Node_Index | Node_Status | Cluster_Status | Cluster_Size |\n+------------+-------------+----------------+--------------+\n|          0 | Synced      | Primary        |            3 |\n+------------+-------------+----------------+--------------+\n\nURL: https://mariadb.com/kb/en/show-wsrep_status/','','https://mariadb.com/kb/en/show-wsrep_status/'),
(406,'PURGE BINARY LOGS',26,'Syntax\n------\n\nPURGE { BINARY | MASTER } LOGS\n  { TO \'log_name\' | BEFORE datetime_expr }\n\nDescription\n-----------\n\nThe PURGE BINARY LOGS statement deletes all the binary log files listed in the\nlog index file prior to the specified log file name or date. BINARY and MASTER\nare synonyms. Deleted log files also are removed from the list recorded in the\nindex file, so that the given log file becomes the first in the list.\n\nThe datetime expression is in the format \'YYYY-MM-DD hh:mm:ss\'.\n\nIf a replica is active but has yet to read from a binary log file you attempt\nto delete, the statement will fail with an error. However, if the replica is\nnot connected and has yet to read from a log file you delete, the file will be\ndeleted, but the replica will be unable to continue replicating once it\nconnects again.\n\nThis statement has no effect if the server was not started with the --log-bin\noption to enable binary logging.\n\nTo list the binary log files on the server, use SHOW BINARY LOGS. To see which\nfiles they are reading, use SHOW SLAVE STATUS (or SHOW REPLICA STATUS from\nMariaDB 10.5.1). You can only delete the files that are older than the oldest\nfile that is used by the slaves.\n\nTo delete all binary log files, use RESET MASTER. To move to a new log file\n(for example if you want to remove the current log file), use FLUSH LOGS\nbefore you execute PURGE LOGS.\n\nIf the expire_logs_days server system variable is not set to 0, the server\nautomatically deletes binary log files after the given number of days. From\nMariaDB 10.6, the binlog_expire_logs_seconds variable allows more precise\ncontrol over binlog deletion, and takes precedence if both are non-zero.\n\nRequires the SUPER privilege or, from MariaDB 10.5.2, the BINLOG ADMIN\nprivilege, to run.\n\nExamples\n--------\n\nPURGE BINARY LOGS TO \'mariadb-bin.000063\';\n\nPURGE BINARY LOGS BEFORE \'2013-04-21\';\n\nPURGE BINARY LOGS BEFORE \'2013-04-22 09:55:22\';\n\nURL: https://mariadb.com/kb/en/purge-binary-logs/','','https://mariadb.com/kb/en/purge-binary-logs/'),
(407,'CACHE INDEX',26,'Syntax\n------\n\nCACHE INDEX                      \n tbl_index_list [, tbl_index_list] ...\n IN key_cache_name\n\ntbl_index_list:\n tbl_name [[INDEX|KEY] (index_name[, index_name] ...)]\n\nDescription\n-----------\n\nThe CACHE INDEX statement assigns table indexes to a specific key cache. It is\nused only for MyISAM tables.\n\nA default key cache exists and cannot be destroyed. To create more key caches,\nthe key_buffer_size server system variable.\n\nThe associations between tables indexes and key caches are lost on server\nrestart. To recreate them automatically, it is necessary to configure caches\nin a configuration file and include some CACHE INDEX (and optionally LOAD\nINDEX) statements in the init file.\n\nExamples\n--------\n\nThe following statement assigns indexes from the tables t1, t2, and t3 to the\nkey cache named hot_cache:\n\nCACHE INDEX t1, t2, t3 IN hot_cache;\n+---------+--------------------+----------+----------+\n| Table   | Op                 | Msg_type | Msg_text |\n+---------+--------------------+----------+----------+\n| test.t1 | assign_to_keycache | status   | OK       |\n| test.t2 | assign_to_keycache | status   | OK       |\n| test.t3 | assign_to_keycache | status   | OK       |\n+---------+--------------------+----------+----------+\n\nImplementation (for MyISAM)\n---------------------------\n\nNormally CACHE INDEX should not take a long time to execute. Internally it\'s\nimplemented the following way:\n\n* Find the right key cache (under LOCK_global_system_variables)\n* Open the table with a TL_READ_NO_INSERT lock.\n* Flush the original key cache for the given file (under key cache lock)\n* Flush the new key cache for the given file (safety)\n* Move the file to the new key cache (under file share lock)\n\nThe only possible long operations are getting the locks for the table and\nflushing the original key cache, if there were many key blocks for the file in\nit.\n\nWe plan to also add CACHE INDEX for Aria tables if there is a need for this.\n\nURL: https://mariadb.com/kb/en/cache-index/','','https://mariadb.com/kb/en/cache-index/'),
(408,'HELP Command',26,'Syntax\n------\n\nHELP search_string\n\nDescription\n-----------\n\nThe HELP command can be used in any MariaDB client, such as the mariadb\ncommand-line client, to get basic syntax help and a short description for most\ncommands and functions.\n\nIf you provide an argument to the HELP command, the mariadb client uses it as\na search string to access server-side help. The proper operation of this\ncommand requires that the help tables in the mysql database be initialized\nwith help topic information.\n\nIf there is no match for the search string, the search fails. Use HELP\ncontents to see a list of the help categories:\n\nHELP contents\nYou asked for help about help category: \"Contents\"\nFor more information, type \'help <item>\', where <item> is one of the following\ncategories:\n Account Management\n Administration\n Compound Statements\n Data Definition\n Data Manipulation\n Data Types\n Functions\n Functions and Modifiers for Use with GROUP BY\n Geographic Features\n Help Metadata\n Language Structure\n Plugins\n Procedures\n Sequences\n Table Maintenance\n Transactions\n User-Defined Functions\n Utility\n\nIf a search string matches multiple items, MariaDB shows a list of matching\ntopics:\n\nHELP drop\nMany help items for your request exist.\nTo make a more specific request, please type \'help <item>\',\nwhere <item> is one of the following\ntopics:\n ALTER TABLE\n DROP DATABASE\n DROP EVENT\n DROP FUNCTION\n DROP FUNCTION UDF\n DROP INDEX\n DROP PACKAGE\n DROP PACKAGE BODY\n DROP PROCEDURE\n DROP ROLE\n DROP SEQUENCE\n DROP SERVER\n DROP TABLE\n DROP TRIGGER\n DROP USER\n DROP VIEW\n\nThen you can enter a topic as the search string to see the help entry for that\ntopic.\n\nThe help is provided with the MariaDB server and makes use of four help tables\nfound in the mysql database: help_relation, help_topic, help_category and\nhelp_keyword. These tables are populated by the mariadb-install-db or\nfill_help_table.sql scripts.\n\nURL: https://mariadb.com/kb/en/help-command/','','https://mariadb.com/kb/en/help-command/'),
(409,'KILL [CONNECTION | QUERY]',26,'Syntax\n------\n\nKILL [HARD | SOFT] { {CONNECTION|QUERY} thread_id | QUERY ID query_id | USER\nuser_name }\n\nDescription\n-----------\n\nEach connection to mysqld runs in a separate thread. You can see which threads\nare running with the SHOW PROCESSLIST statement and kill a thread with the\nKILL thread_id statement. KILL allows the optional CONNECTION or QUERY\nmodifier:\n\n* KILL CONNECTION is the same as KILL with no\n modifier: It terminates the connection associated with the given thread or\nquery id.\n* KILL QUERY terminates the statement that the connection thread_id is\n currently executing, but leaves the connection itself intact.\n* KILL QUERY ID terminates the query by query_id, leaving the connection\nintact.\n\nIf a connection is terminated that has an active transaction, the transaction\nwill be rolled back. If only a query is killed, the current transaction will\nstay active. See also idle_transaction_timeout.\n\nIf you have the PROCESS privilege, you can see all threads. If you have the\nSUPER privilege, or, from MariaDB 10.5.2, the CONNECTION ADMIN privilege, you\ncan kill all threads and statements. Otherwise, you can see and kill only your\nown threads and statements.\n\nKilling queries that repair or create indexes on MyISAM and Aria tables may\nresult in corrupted tables. Use the SOFT option to avoid this!\n\nThe HARD option (default) kills a command as soon as possible. If you use\nSOFT, then critical operations that may leave a table in an inconsistent state\nwill not be interrupted. Such operations include REPAIR and INDEX creation for\nMyISAM and Aria tables (REPAIR TABLE, OPTIMIZE TABLE).\n\nKILL ... USER username will kill all connections/queries for a given user.\nUSER can be specified one of the following ways:\n\n* username  (Kill without regard to hostname)\n* username@hostname\n* CURRENT_USER or CURRENT_USER()\n\nIf you specify a thread id and that thread does not exist, you get the\nfollowing error:\n\nERROR 1094 (HY000): Unknown thread id: <thread_id>\n\nIf you specify a query id that doesn\'t exist, you get the following error:\n\nERROR 1957 (HY000): Unknown query id: <query_id>\n\nHowever, if you specify a user name, no error is issued for non-connected (or\neven non-existing) users. To check if the connection/query has been killed,\nyou can use the ROW_COUNT() function.\n\nA client whose connection is killed receives the following error:\n\nERROR 1317 (70100): Query execution was interrupted\n\nTo obtain a list of existing sessions, use the SHOW PROCESSLIST statement or\nquery the Information Schema PROCESSLIST table.\n\nNote: You cannot use KILL with the Embedded MariaDB Server library because the\nembedded server merely runs inside the threads of the host application. It\ndoes not create any connection threads of its own.\n\nNote: You can also use mariadb-admin kill thread_id [,thread_id...] to kill\nconnections. To get a list of running queries, use mariadb-admin processlist.\nSee mariadb-admin.\n\nPercona Toolkit contains a program, pt-kill that can be used to automatically\nkill connections that match certain criteria. For example, it can be used to\nterminate idle connections, or connections that have been busy for more than\n60 seconds.\n\nURL: https://mariadb.com/kb/en/kill/','','https://mariadb.com/kb/en/kill/'),
(411,'RESET',26,'Syntax\n------\n\nRESET reset_option [, reset_option] ...\n\nDescription\n-----------\n\nThe RESET statement is used to clear the state of various server operations.\nYou must have the RELOAD privilege to execute RESET.\n\nRESET acts as a stronger version of the FLUSH statement.\n\nThe different RESET options are:\n\n+---------------------------+------------------------------------------------+\n| Option                    | Description                                    |\n+---------------------------+------------------------------------------------+\n| SLAVE                     | Deletes all relay logs from the slave and      |\n| [\"connection_name\"] [ALL] | reset the replication position in the master   |\n|                           | binary log.                                    |\n+---------------------------+------------------------------------------------+\n| MASTER                    | Deletes all old binary logs, makes the binary  |\n|                           | index file (--log-bin-index) empty and         |\n|                           | creates a new binary log file.  This is        |\n|                           | useful when you want to reset the master to    |\n|                           | an initial state. If you want to just delete   |\n|                           | old, not used binary logs, you should use the  |\n|                           | PURGE BINARY LOGS command.                     |\n+---------------------------+------------------------------------------------+\n| QUERY CACHE               | Removes all queries from the query cache. See  |\n|                           | also FLUSH QUERY CACHE.                        |\n+---------------------------+------------------------------------------------+\n\nURL: https://mariadb.com/kb/en/reset/','','https://mariadb.com/kb/en/reset/'),
(412,'SHUTDOWN',26,'Syntax\n------\n\nSHUTDOWN [WAIT FOR ALL { SLAVES | REPLICAS } ]\n\nDescription\n-----------\n\nThe SHUTDOWN command shuts the server down.\n\nWAIT FOR ALL REPLICAS / SLAVES\n------------------------------\n\nMariaDB starting with 10.4.4\n----------------------------\nThe WAIT FOR ALL SLAVES option was first added in MariaDB 10.4.4. WAIT FOR ALL\nREPLICAS has been a synonym since MariaDB 10.5.1.\n\nWhen a primary server is shutdown and it goes through the normal shutdown\nprocess, the primary kills client threads in random order. By default, the\nprimary also considers its binary log dump threads to be regular client\nthreads. As a consequence, the binary log dump threads can be killed while\nclient threads still exist, and this means that data can be written on the\nprimary during a normal shutdown that won\'t be replicated. This is true even\nif semi-synchronous replication is being used.\n\nIn MariaDB 10.4 and later, this problem can be solved by shutting down the\nserver with the SHUTDOWN command and by providing the WAIT FOR ALL\nREPLICAS/WAIT FOR ALL SLAVES option to the command. For example:\n\nSHUTDOWN WAIT FOR ALL REPLICAS;\n\nWhen the WAIT FOR ALL REPLICAS option is provided, the server only kills its\nbinary log dump threads after all client threads have been killed, and it only\ncompletes the shutdown after the last binary log has been sent to all\nconnected replicas.\n\nSee Replication Threads: Binary Log Dump Threads and the Shutdown Process for\nmore information.\n\nRequired Permissions\n--------------------\n\nOne must have a SHUTDOWN privilege (see GRANT) to use this command. It is the\nsame privilege one needs to use the mariadb-admin shutdown command.\n\nShutdown for Upgrades\n---------------------\n\nIf you are doing a shutdown to migrate to another major version of MariaDB,\nplease ensure that the innodb_fast_shutdown variable is not 2 (fast crash\nshutdown). The default of this variable is 1.\n\nExample\n-------\n\nThe following example shows how to create an event which turns off the server\nat a certain time:\n\nCREATE EVENT `test`.`shutd`\n  ON SCHEDULE\n    EVERY 1 DAY\n    STARTS \'2014-01-01 20:00:00\'\n  COMMENT \'Shutdown Maria when the office is closed\'\nDO BEGIN\n  SHUTDOWN;\nEND;\n\nOther Ways to Stop mysqld\n-------------------------\n\nYou can use the mariadb-admin shutdown command to take down mysqld cleanly.\n\nYou can also use the system kill command on Unix with signal SIGTERM (15)\n\nkill -SIGTERM pid-of-mysqld-process\n\nYou can find the process number of the server process in the file that ends\nwith .pid in your data directory.\n\nThe above is identical to mariadb-admin shutdown.\n\nOn windows you should use:\n\nNET STOP MySQL\n\nURL: https://mariadb.com/kb/en/shutdown/','','https://mariadb.com/kb/en/shutdown/'),
(413,'USE [DATABASE]',26,'Syntax\n------\n\nUSE db_name\n\nIn MariaDB 11.3 one can also use\n\nUSE DATABASE db_name;\n\nDescription\n-----------\n\nThe \'USE db_name\' statement tells MariaDB to use the db_name database as the\ndefault (current) database for subsequent statements. The database remains the\ndefault until the end of the session or another USE statement is issued:\n\nUSE db1;\nSELECT COUNT(*) FROM mytable;   # selects from db1.mytable\nUSE db2;\nSELECT COUNT(*) FROM mytable;   # selects from db2.mytable\n\nThe DATABASE() function (SCHEMA() is a synonym) returns the default database.\n\nAnother way to set the default database is specifying its name at mariadb\ncommand line client startup.\n\nOne cannot use USE DATABASE to a database one has no privileges to. The reason\nis that a user with no privileges to a database should not be able to know if\na database exists or not.\n\nURL: https://mariadb.com/kb/en/use-database/','','https://mariadb.com/kb/en/use-database/'),
(421,'JOIN Syntax',27,'Description\n-----------\n\nMariaDB supports the following JOIN syntaxes for the table_references part of\nSELECT statements and multiple-table DELETE and UPDATE statements:\n\ntable_references:\n  table_reference [, table_reference] ...\n\ntable_reference:\n  table_factor\n | join_table\n\ntable_factor:\n  tbl_name [PARTITION (partition_list)]\n    [query_system_time_period_specification] [[AS] alias] [index_hint_list]\n | table_subquery [query_system_time_period_specification] [AS] alias\n | ( table_references )\n | { ON table_reference LEFT OUTER JOIN table_reference\n    ON conditional_expr }\n\njoin_table:\n  table_reference [INNER | CROSS] JOIN table_factor [join_condition]\n | table_reference STRAIGHT_JOIN table_factor\n | table_reference STRAIGHT_JOIN table_factor ON conditional_expr\n | table_reference {LEFT|RIGHT} [OUTER] JOIN table_reference join_condition\n | table_reference NATURAL [{LEFT|RIGHT} [OUTER]] JOIN table_factor\n\njoin_condition:\n  ON conditional_expr\n | USING (column_list)\n\nquery_system_time_period_specification:\n  FOR SYSTEM_TIME AS OF point_in_time\n | FOR SYSTEM_TIME BETWEEN point_in_time AND point_in_time\n | FOR SYSTEM_TIME FROM point_in_time TO point_in_time\n | FOR SYSTEM_TIME ALL\n\npoint_in_time:\n  [TIMESTAMP] expression\n | TRANSACTION expression\n\nindex_hint_list:\n  index_hint [, index_hint] ...\n\nindex_hint:\n  USE {INDEX|KEY}\n   [{FOR {JOIN|ORDER BY|GROUP BY}] ([index_list])\n | IGNORE {INDEX|KEY}\n   [{FOR {JOIN|ORDER BY|GROUP BY}] (index_list)\n | FORCE {INDEX|KEY}\n   [{FOR {JOIN|ORDER BY|GROUP BY}] (index_list)\n\nindex_list:\n  index_name [, index_name] ...\n\nA table reference is also known as a join expression.\n\nEach table can also be specified as db_name.tabl_name. This allows to write\nqueries which involve multiple databases. See Identifier Qualifiers for syntax\ndetails.\n\nThe syntax of table_factor is extended in comparison with the SQL Standard.\nThe latter accepts only table_reference, not a list of them inside a pair of\nparentheses.\n\nThis is a conservative extension if we consider each comma in a list of\ntable_reference items as equivalent to an inner join. For example:\n\nSELECT * FROM t1 LEFT JOIN (t2, t3, t4)\n        ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)\n\nis equivalent to:\n\nSELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4)\n        ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)\n\nIn MariaDB, CROSS JOIN is a syntactic equivalent to INNER JOIN (they can\nreplace each other). In standard SQL, they are not equivalent. INNER JOIN is\nused with an ON clause, CROSS JOIN is used otherwise.\n\nIn general, parentheses can be ignored in join expressions containing only\ninner join operations. MariaDB also supports nested joins (see\nhttp://dev.mysql.com/doc/refman/5.1/en/nested-join-optimization.html).\n\nSee System-versioned tables for more information about FOR SYSTEM_TIME syntax.\n\nIndex hints can be specified to affect how the MariaDB optimizer makes use of\nindexes. For more information, see How to force query plans.\n\nExamples\n--------\n\nSELECT left_tbl.*\n FROM left_tbl LEFT JOIN right_tbl ON left_tbl.id = right_tbl.id\n WHERE right_tbl.id IS NULL;\n\nURL: https://mariadb.com/kb/en/join-syntax/','','https://mariadb.com/kb/en/join-syntax/'),
