Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-24891

Document mariadb_schema data type qualifier

Details

    Description

      When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

      SET SQL_mode=ORACLE;
      		 
      CREATE OR REPLACE TABLE t1 (
      		 
        d DATE
      		 
      );
      		 
      SHOW CREATE TABLE t1;


      +-------+---------------------------------------------------+
      		 
      | Table | Create Table                                      |
      		 
      +-------+---------------------------------------------------+
      		 
      | t1    | CREATE TABLE "t1" (
      		 
        "d" datetime DEFAULT NULL
      		 
      ) |
      		 
      +-------+---------------------------------------------------+

      Notice, DATE was translated to DATETIME.

      This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

      SET sql_mode=DEFAULT;
      		 
      CREATE OR REPLACE TABLE t1 (
      		 
        d DATE
      		 
      );
      		 
      SET SQL_mode=ORACLE;
      		 
      SHOW CREATE TABLE t1;

      Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

      CREATE TABLE "t1" (
      		 
        "d" date DEFAULT NULL
      		 
      );

      which had two problems:

      • It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
      • It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).

      To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

      SET sql_mode=DEFAULT;
      		 
      CREATE OR REPLACE TABLE t1 (
      		 
        d DATE
      		 
      );
      		 
      SET SQL_mode=ORACLE;
      		 
      SHOW CREATE TABLE t1;


      +-------+--------------------------------------------------------------+
      		 
      | Table | Create Table                                                 |
      		 
      +-------+--------------------------------------------------------------+
      		 
      | t1    | CREATE TABLE "t1" (
      		 
        "d" mariadb_schema.date DEFAULT NULL
      		 
      ) |
      		 
      +-------+--------------------------------------------------------------+

      When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation and interprets the data type literally, so for example mariadb_schema.DATE is interpreted as the traditional MariaDB DATE data type, no matter what the current sql_mode is.

      Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT, or when a non-ambiguous data type is displayed.

      Note, the "mariadb_schema" prefix can be used with any data type, including non-ambiguous ones:

      CREATE OR REPLACE TABLE t1 (a mariadb_schema.INT);
      		 
      SHOW CREATE TABLE t1;


      +-------+--------------------------------------------------+
      		 
      | Table | Create Table                                     |
      		 
      +-------+--------------------------------------------------+
      		 
      | t1    | CREATE TABLE "t1" (
      		 
        "a" int(11) DEFAULT NULL
      		 
      ) |
      		 
      +-------+--------------------------------------------------+

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          bar Alexander Barkov created issue -
          bar Alexander Barkov made changes -
          Field Original Value New Value
          Priority Major [ 3 ] Critical [ 2 ]
          bar Alexander Barkov made changes -
          Description
          When running in ORACLE mode, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}


          Now suppose a user creates a table with a column of the DATE data type in the default mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10 a SHOW CREATE TABLE statement for this table displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}


          Now suppose a user creates a table with a column of the DATE data type in the default mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10 a SHOW CREATE TABLE statement for this table displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}


          Now suppose a user creates a table with a column of the DATE data type in the default mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10 a SHOW CREATE TABLE statement for this table displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}


          Now suppose a user creates a table with a column of the traditional MariaDB DATE data type in the default mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10 a SHOW CREATE TABLE statement for this table displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}


          Now suppose a user creates a table with a column of the traditional MariaDB DATE data type in the default mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10 a SHOW CREATE TABLE statement for this table displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}


          Now suppose a user creates a table with a column of the traditional MariaDB DATE data type in the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10 a SHOW CREATE TABLE statement for this table displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}


          Now suppose a user creates a table with a column of the traditional MariaDB DATE data type in the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10 a SHOW CREATE TABLE statement for this table displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}


          Now suppose a user creates a table with a column of the traditional MariaDB DATE data type in the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}


          Now suppose a user creates a table with a column of the traditional MariaDB DATE data type in the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Now suppose a user creates a table with a column of the traditional MariaDB DATE data type in the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Now suppose a user creates a table with a column of the traditional MariaDB DATE data type in the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type in the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type in the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its now clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5 10, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of the SQL standard qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type iterally, e.g. mariadb_schema.DATE is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type literally, e.g. {{mariadb_schema.DATE}} is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type literally, e.g. {{mariadb_schema.DATE}} is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type literally, so for example {{mariadb_schema.DATE}} is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type literally, so for example {{mariadb_schema.DATE}} is interpreted as traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type literally, so for example {{mariadb_schema.DATE}} is interpreted as the traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation (e.g. DATE to DATETIME in sql_mode=ORACLE) and interprets the data type literally, so for example {{mariadb_schema.DATE}} is interpreted as the traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation and interprets the data type literally, so for example {{mariadb_schema.DATE}} is interpreted as the traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation and interprets the data type literally, so for example {{mariadb_schema.DATE}} is interpreted as the traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation and interprets the data type literally, so for example {{mariadb_schema.DATE}} is interpreted as the traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT, or when a non-ambiguous data type is displayed.
          bar Alexander Barkov made changes -
          Description When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation and interprets the data type literally, so for example {{mariadb_schema.DATE}} is interpreted as the traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT, or when a non-ambiguous data type is displayed.
          		When running with sql_mode=ORACLE, MariaDB server translates the data type "DATE" to "DATETIME", for better Oracle compatibility:

          {code:sql}
          SET SQL_mode=ORACLE;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+---------------------------------------------------+
          | Table | Create Table |
          +-------+---------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" datetime DEFAULT NULL
          ) |
          +-------+---------------------------------------------------+
          {noformat}
          Notice, DATE was translated to DATETIME.

          This translation may cause some ambiguity. Suppose a user creates a table with a column of the traditional MariaDB DATE data type using the default sql_mode, but then switches to sql_mode=ORACLE and runs a SHOW CREATE TABLE statement:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}

          Before the versions 10.3.24, 10.4.14, 10.5.5, the above script displayed:

          {code:sql}
          CREATE TABLE "t1" (
            "d" date DEFAULT NULL
          );
          {code}

          which had two problems:
          - It was confusing for the reader: its not clear if it is the traditional MariaDB DATE, or is it Oracle-alike date (which is actually DATETIME)?
          - It broke replication and caused data type mismatch on the master and on the slave (see MDEV-19632).


          To address this problem, starting from the mentioned versions, MariaDB uses the idea of qualified data types:

          {code:sql}
          SET sql_mode=DEFAULT;
          CREATE OR REPLACE TABLE t1 (
            d DATE
          );
          SET SQL_mode=ORACLE;
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "d" mariadb_schema.date DEFAULT NULL
          ) |
          +-------+--------------------------------------------------------------+
          {noformat}

          When the server sees the "mariadb_schema" qualifier, it disables sql_mode specific data type translation and interprets the data type literally, so for example {{mariadb_schema.DATE}} is interpreted as the traditional MariaDB DATE data type, no matter what the current sql_mode is.

          Note, the "mariadb_schema" prefix is displayed only when the data type name would be ambiguous otherwise. As of version 10.5.9, the prefix is displayed together with MariaDB DATE when SHOW CREATE TABLE is executed in sql_mode=ORACLE. The prefix is not displayed when SHOW CREATE TABLE is executed in sql_mode=DEFAULT, or when a non-ambiguous data type is displayed.

          Note, the "mariadb_schema" prefix can be used with any data type, including non-ambiguous ones:
          {code:sql}
          CREATE OR REPLACE TABLE t1 (a mariadb_schema.INT);
          SHOW CREATE TABLE t1;
          {code}
          {noformat}
          +-------+--------------------------------------------------+
          | Table | Create Table |
          +-------+--------------------------------------------------+
          | t1 | CREATE TABLE "t1" (
            "a" int(11) DEFAULT NULL
          ) |
          +-------+--------------------------------------------------+
          {noformat}
          serg Sergei Golubchik made changes -
          Assignee Michael Widenius [ monty ] Ian Gilfillan [ greenman ]
          serg Sergei Golubchik made changes -
          Fix Version/s N/A [ 14700 ]
          Fix Version/s 10.5.9 [ 25109 ]
          bar Alexander Barkov added a comment -

          Hi greenman. Monty has already put this text (with some additions) to https://mariadb.com/kb/en/mariadb_schema/.

          Can you please check it? Thanks!

          bar Alexander Barkov added a comment - Hi greenman . Monty has already put this text (with some additions) to https://mariadb.com/kb/en/mariadb_schema/ . Can you please check it? Thanks!
          greenman Ian Gilfillan made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]
          serg Sergei Golubchik made changes -
          Workflow MariaDB v3 [ 119211 ] MariaDB v4 [ 134393 ]

          People

            greenman Ian Gilfillan
            bar Alexander Barkov
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.