summaryrefslogtreecommitdiff
path: root/sql/sql_schema.cc
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-31153 New methods Schema::make_item_func_* for REPLACE, SUBSTRING, TRIMAlexander Barkov2023-04-291-0/+61
| | | | | | | | | | Adding virtual methods to class Schema: make_item_func_replace() make_item_func_substr() make_item_func_trim() This is a non-functional preparatory change for MDEV-27744.
* MDEV-19632 Replication aborts with ER_SLAVE_CONVERSION_FAILED upon CREATE ↵Alexander Barkov2020-08-011-0/+80
... SELECT in ORACLE mode - Adding optional qualifiers to data types: CREATE TABLE t1 (a schema.DATE); Qualifiers now work only for three pre-defined schemas: mariadb_schema oracle_schema maxdb_schema These schemas are virtual (hard-coded) for now, but may turn into real databases on disk in the future. - mariadb_schema.TYPE now always resolves to a true MariaDB data type TYPE without sql_mode specific translations. - oracle_schema.DATE translates to MariaDB DATETIME. - maxdb_schema.TIMESTAMP translates to MariaDB DATETIME. - Fixing SHOW CREATE TABLE to use a qualifier for a data type TYPE if the current sql_mode translates TYPE to something else. The above changes fix the reported problem, so this script: SET sql_mode=ORACLE; CREATE TABLE t2 AS SELECT mariadb_date_column FROM t1; is now replicated as: SET sql_mode=ORACLE; CREATE TABLE t2 (mariadb_date_column mariadb_schema.DATE); and the slave can unambiguously treat DATE as the true MariaDB DATE without ORACLE specific translation to DATETIME. Similar, SET sql_mode=MAXDB; CREATE TABLE t2 AS SELECT mariadb_timestamp_column FROM t1; is now replicated as: SET sql_mode=MAXDB; CREATE TABLE t2 (mariadb_timestamp_column mariadb_schema.TIMESTAMP); so the slave treats TIMESTAMP as the true MariaDB TIMESTAMP without MAXDB specific translation to DATETIME.