The following statement usually is valid and the function returns 1. But sometimes it is invalid and sometimes the function returns 0.
CREATE FUNCTION f() RETURNS INT DETERMINISTIC BEGIN DECLARE a CHAR DEFAULT 'a'; IF a = 0 || a > 0 THEN RETURN 1; END IF; RETURN 0; END;
First, consider that "||" is usually the same as "OR" because that's the default. But if sql_mode is 'ansi' and the DBMS is MySQL 8.0, then "||" is the operator for concatenating strings. So the meaning of the IF condition changes, and it becomes false.
Second, consider that the function is written with SQL/PSM syntax. But if sql_mode is 'oracle' and the DBMS is MariaDB 10.3, then the function has to be written with PL/SQL syntax. And the requirements differ as soon as the word "RETURNS" comes along, so the result is a syntax error.
Our lesson is: you can't know a statement's meaning if you don't know whether somebody said "SET sql_mode=..." earlier.
Usually SET sql_mode is a DIRECTIVE with the same sense as "pragma" in C, it is telling the compiler or interpreter how to treat the syntax of following statements. And in fact Oracle and SQLite actually use the word "pragma" in that sense. I use C pragmas despite a nagging feeling that somewhere there is a jeremiad blog post about how they're as bad as goto and #ifndef, and I'll recommended certain sql_mode values enthusiastically. The only strong warning is: be consistent, so you don't end up with idiocy like my example above.
(By the way, speaking of C, one of the possible settings is "treat warnings as errors", and if there were such a mode in MySQL/MariaDB then my example function wouldn't have worked. But there isn't an exact equivalent.)
The manuals' lists are more complete, but this list has more advice.
ANSI: Avoid. It won't deliver "American National Standards Institute" SQL. And try this:
SET @@sql_mode=''; CREATE TABLE x (s1 INT); SHOW CREATE TABLE x; SET @@sql_mode='ANSI'; SHOW CREATE TABLE x;
Compare the SHOW CREATE TABLE results. Before:
Notice that critical information is missing in the 'ANSI' result -- information that would be necessary to reproduce the table correctly. So, although using standard SQL is good, the way to do it is by setting other SQL-mode settings that don't have such ugly side effects.
TRADITIONAL: Don't avoid. This has very limited effect, it only "treats warnings as errors" if you're changing a database value, and it's only safe if you're using a storage engine that can do statement rollbacks, such as InnoDB. But most of the time it's good to disallow bad data, which is why it's "traditional" (which stands for "what everybody else has done for decades").
ALLOW_INVALID_DATES, Avoid. This made sense when the objective was to avoid "invalid data" errors because transactions were hard to roll back. That's less of a concern nowadays.
ANSI_QUOTES. Probably don't avoid. If you frequently have single quotes inside string literals, such as "O'Hara", it's understandable that you'd want ANSI_QUOTES to be off. With ANSI_QUOTES on, you have to say 'O''Hara'' and it's possible to lose the duplicated '. But ANSI_QUOTES are standard SQL.
HIGH_NOT_PRECEDENCE, NO_BACKSLASH_ESCAPES, NO_ZERO_DATE, NO_ZERO_IN_DATE, ONLY_FULL_GROUP_BY, PIPES_AS_CONCAT, REAL_AS_FLOAT. Don't avoid. These are standard SQL.
PAD_CHAR_TO_FULL_LENGTH, ERROR_FOR_DIVISION_BY_ZERO. Avoid in MySQL. They're deprecated.
IGNORE_SPACE. Avoid. The effect on naming is too great, because so many new reserved words appear.
NO_AUTO_VALUE_ON_ZERO. Avoid. This is a case where a non-standard feature can be treated in more than one way, so it's hard to care.
SIMULTANEOUS_ASSIGNMENT. See my earlier blog post, The simultaneous_assignment mode in MariaDB 10.3.5.
STRICT_ALL_TABLES + STRICT_TRANS_TABLES. Don't avoid. Perhaps you have some way of cleaning up messes after they're added, but setting is simpler.
TIME_TRUNCATE_FRACTIONAL. Avoid but not forever. I hear from reliable sources that there is some strange behaviour that will be corrected real soon.
DB2,MAXDB,MSSQL,MYSQL323,MYSQL40,ORACLE,POSTGRESQL, etc. Mostly avoid. These have disappeared in MySQL 8.0. They never delivered a serious amount of compatibility with other DBMSs. The only one that is worth any consideration is ORACLE in MariaDB 10.3, because it affects quite a few Oracle-related matters including PL/SQL support.
There are many variants.
SET sql_mode=value; SET @sql_mode=value; SET @@sql_mode=value; SET SESSION | GLOBAL | PERSIST | PERSIST_ONLY sql_mode=value; SET @@session.|@@global.|@@persist.|@@persist_only.sql_mode=value;
where value can be a string literal containing a mode name
or a series of mode names as in 'ansi,ansi', or a variable, or even
a keyword. When it's a keyword, it can be DEFAULT or
it can be a mode name -- this seems to be undocumented but
I've seen that one of the MariaDB developers likes to use
The good news is that the setting is transient and local. By "transient" I mean its effect ends when the routine ends or the session ends. By "local" I mean changes won't affect other users whose sessions already started. And both these non-effects are good. Wouldn't it be awful if your SQL statements stopped working because you invoked a function that changed sql_mode, or because some other user on the system found a way to change it for everybody while they were online?
Version 1.0.7 of our open-source ocelotgui MySQL/MariaDB client is out, and one of the features is that it recognizes all the current syntax of MySQL 8.0 and MariaDB 10.3, including the sql_mode bizarreness (though we can't get it right if the source value is a variable). That means that it won't get confused when parsing batches of SQL statements that include statements that change the dialect.
The major feature is that the debugger can now debug routines written in MySQL 8.0, and routines written in MariaDB 10.3 with sql_mode=oracle -- that is, with PL/SQL syntax.
As usual, download for various Linux distros and for Windows is via github.