Change is bad. Change will introduce bugs. Changing SQL_MODE is a major change to the way that MySQL works which will cause new bugs in existing code- therefore doing so in an existing application is significantly risky.

One case where changing SQL_MODE might be acceptable is if you’re doing such a major change anyway that every single query must be tested- for example upgrading the MySQL version.

Typical open source PHP applications are generally so buggy and have such poor error handling that even diagnosing or detecting bugs caused by SQL_MODE will be very time consuming. Convincing their maintainers that these are bugs proves difficult (in my experience). Don’t use such applications in production.

For a new application- great - provided you are completely sure that the developers’ test environments will also use that setting (which should be easy, as your developers must always use a system which is as close in configuration to production as possible).

Mark

“One could also argue that MySQL should make the default SQL_MODE at least TRADITIONAL, and that only when you want backward compatibility should you then change the SQL_MODE.”

I’d like that too, except that many applications (esp. the typical PHP webapps) will instantly crap out on you (Try it). In fact, many applications do not withstand any non-default options, like the default engine, default auto_commit etc. (so it’s not just confined to SQL_MODE)

As for sql_mode, both ANSI and TRADITIONAL are most likely to sink the typical PHP app. Many PHP apps simply use double quotes to delimit strings in their SQL statements, and many schemas simply rely on ‘0000-00-00′ dates.

I have been told by some appdevs that I am shooting myself in the foot by changing things like the sql_mode at the server level, and that’s only fair that I should suffer from problems with their apps.

I disagree.

Personally I would urge every application developer to always have their code explicitly set the sql_mode (and any other settings, such as autocommit mode) at the session level immediately after connecting to MySQL to what suits their application best. For most applications that would boil down to a single statement:

SET sql_mode := ”, autocommit = true, storage_engine = MyISAM;

If you look at the installation documentation for most PHP apps, you will almost never see any reference to these kinds of MySQL config requirements. They simply assume a default installation, always.

I don’t see this getting better anytime soon. If MySQL would change the default configuration, it would just lead to a lot of broken apps and scrolls and scrolls of slashdot rants.