I am not sure what you mean by a developer perspective. My point is that it depends on the application whether things like zero dates and zero in dates are permissable.

I agree the case where multiple database users access the same tables is a problem.

I am sure you are aware that for stored procedures, views and events the sql_mode that was in effect at DDL time is stored together with the definitions of these object. At runtime, that sql_mode is applied in order to allow the code to run predictably.

Well, this always made me wonder….why should tables and triggers be excluded from this? Logically it seems to be in the same league, but I suspect it cannot be implemented in an efficient way for tables.

regards,
Roland

@Schlomi: sure, feel free to quote me. (I guess it would be best to include a link to this comment thread so ppl can verify real quick who said what, but this is just a suggestion)

Actually, what I meant was container privileges like:

GRANT SET [SESSION|GLOBAL] SQL_MODE TO user[@host]

But your suggestion gave me the idea that it would in addition be nice to do:

CREATE USER user[@host] IDENTIFIED BY ‘pasword’
DEFAULT SQL_MODE = ‘….’;

(and this would assign the default sql_mode on connect)

As for sql_mode not having to exist at all – well, that would be for the best. But it is not going to happen – not with MySQL. Things are as they are because they evolved that way. Backwards compatibility is being considered by the MySQL dev

@Lukas: I don’t need to support legacy apps. Or well, I do, but this was not what I was thinking about. I like to try out lots of these php apps like wordpress, joomla, drupal, dotProject etc. whatever I feel like I might need at some point. I find that in many, many cases, the installers of these apps break on my perhaps mysql-wise unorthodox settings. I suppose I could have a completely default MySQL installation on the side, but my stance remains that, given the current state of MySQL, it should be on the application to ensure the right SQL_MODE is set right after connecting to the database server.

I have written about a few of my experiences in this regard here:

http://rpbouman.blogspot.com/2007/04/so-wordpress-does-not-like-mysql-sql.html
http://rpbouman.blogspot.com/2007/04/guess-whatwordpress-does-not-like.html

I have also filed a dotProject bug relating to this, and this was solved (Kudos to Adam Donnison!)

http://bugs.dotproject.net/view.php?id=2323

I see your point. If I understand your intention, though, you’re referring to a completely new set of privileges, integrated into the privileges system.
That in itself is just fine. In my opinion, though, sql_mode must still not exist.
So for being able to set zero for dates you would
GRANT ZERO_ON_DATE ON world.* TO ’someuser’@’somehost’
But that user should *not* be able to
SET sql_mode=’ZERO_ON_DATE’
How does that sound?

With your permission, I would like to quote you on a post I’m writing on the subject.

Regards,
Shlomi

sure they can, provided they can’t acces each others schemas. I still don’t see any issue with mixing modes provided different schemas are used in isolation, which is effectively achieved by issuing proper object/schema privileges

Another point is that the sqlmode also contains a number of things that have nothing todo with “strictness”, such as the PIPES_AS_CONCAT you mentioned (other examples are ignore space, double quotes for identifiers and a bunch more).

regards,

Roland