1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-27 18:02:13 +03:00
Commit Graph

11 Commits

Author SHA1 Message Date
2b6d241ee4 MDEV-27744 LPAD in vcol created in ORACLE mode makes table corrupted in non-ORACLE
The crash happened with an indexed virtual column whose
value is evaluated using a function that has a different meaning
in sql_mode='' vs sql_mode=ORACLE:

- DECODE()
- LTRIM()
- RTRIM()
- LPAD()
- RPAD()
- REPLACE()
- SUBSTR()

For example:

CREATE TABLE t1 (
  b VARCHAR(1),
  g CHAR(1) GENERATED ALWAYS AS (SUBSTR(b,0,0)) VIRTUAL,
  KEY g(g)
);

So far we had replacement XXX_ORACLE() functions for all mentioned function,
e.g. SUBSTR_ORACLE() for SUBSTR(). So it was possible to correctly re-parse
SUBSTR_ORACLE() even in sql_mode=''.

But it was not possible to re-parse the MariaDB version of SUBSTR()
after switching to sql_mode=ORACLE. It was erroneously mis-interpreted
as SUBSTR_ORACLE().

As a result, this combination worked fine:

SET sql_mode=ORACLE;
CREATE TABLE t1 ... g CHAR(1) GENERATED ALWAYS AS (SUBSTR(b,0,0)) VIRTUAL, ...;
INSERT ...
FLUSH TABLES;
SET sql_mode='';
INSERT ...

But the other way around it crashed:

SET sql_mode='';
CREATE TABLE t1 ... g CHAR(1) GENERATED ALWAYS AS (SUBSTR(b,0,0)) VIRTUAL, ...;
INSERT ...
FLUSH TABLES;
SET sql_mode=ORACLE;
INSERT ...

At CREATE time, SUBSTR was instantiated as Item_func_substr and printed
in the FRM file as substr(). At re-open time with sql_mode=ORACLE, "substr()"
was erroneously instantiated as Item_func_substr_oracle.

Fix:

The fix proposes a symmetric solution. It provides a way to re-parse reliably
all sql_mode dependent functions to their original CREATE TABLE time meaning,
no matter what the open-time sql_mode is.

We take advantage of the same idea we previously used to resolve sql_mode
dependent data types.

Now all sql_mode dependent functions are printed by SHOW using a schema
qualifier when the current sql_mode differs from the function sql_mode:

SET sql_mode='';
CREATE TABLE t1 ... SUBSTR(a,b,c) ..;
SET sql_mode=ORACLE;
SHOW CREATE TABLE t1;   ->   mariadb_schema.substr(a,b,c)

SET sql_mode=ORACLE;
CREATE TABLE t2 ... SUBSTR(a,b,c) ..;
SET sql_mode='';
SHOW CREATE TABLE t1;   ->   oracle_schema.substr(a,b,c)

Old replacement names like substr_oracle() are still understood for
backward compatibility and used in FRM files (for downgrade compatibility),
but they are not printed by SHOW any more.
2023-11-08 15:01:20 +04:00
2f88bd2da2 MDEV-20634 Report disallowed subquery errors as such (instead of parse error) 2019-09-20 10:36:20 +04:00
47b7ca629f MDEV-18796 Synchronize PS grammar between sql_yacc.yy and sql_yacc_ora.yy 2019-03-03 07:20:15 +04:00
b8f906dd4b MDEV-12846 sql_mode=ORACLE: using Oracle-style placeholders in direct query execution makes the server crash 2017-11-15 14:18:46 +04:00
012fbc15cf MDEV-12478 CONCAT function inside view casts values incorrectly with Oracle sql_mode 2017-04-11 19:32:55 +04:00
08799831cc MDEV-11880 sql_mode=ORACLE: Make the concatenation operator ignore NULL arguments
Now when sql_mode=ORACLE, the concatenation operator || treats
NULLs as empty strings.

Based on the contributed patch from Jérôme Brauge.
2017-04-05 15:02:55 +04:00
f7043858ba MDEV-10866 Extend PREPARE and EXECUTE IMMEDIATE to understand expressions
MDEV-10867 PREPARE..EXECUTE is not consistent about non-ASCII characters

Adding Oracle specific tests
2017-04-05 15:02:52 +04:00
a2a196c04c MDEV-10709 Expressions as parameters to Dynamic SQL
Adding Oracle-specific tests for stored functions as EXECUTE..USING parameters.
2017-04-05 15:02:50 +04:00
417c8c9daf MDEV-10585 EXECUTE IMMEDIATE statement
Adding Oracle specific tests
2017-04-05 15:02:50 +04:00
c2c45c55ce MDEV-10709 Expressions as parameters to Dynamic SQL
Adding Oracle specific tests
2017-04-05 15:02:49 +04:00
ec527face3 MDEV-10801 sql_mode: dynamic SQL placeholders 2017-04-05 15:02:49 +04:00