NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
MySQL is just trying to cater to us scripting folk (Score:1)
For instance...
perl -wle "print '111|1' == 111"javascript:alert(parseInt("111|1"))Granted, the perl example throws a warning, but it does evaluate that statement as true.
You may consider it a bug; others might consider it a feature. And if you were to change how "111|1" gets cast to a number, or return an error for comparing a varchar to a number, who knows what that would break/fix.
Incidentally, SQLite and PostgreSQL don't have this problem/feature.
Re: (Score:2)
Yes, and I mentioned that it was using a similar algorithm to Perl. But, of course, Perl users can choose which conversion is used by using either "eq" or "==". MySQL users don't appear to have a choice.
Of course. That's always a danger when you release buggy code - people can come to rely on the bugs. Maybe they should
Re: (Score:2)
The difference is that, in theory, MySQL is a database. Databases should be strict and cranky, because they're the authority for your important data.
I expect my scripting language to act cute and helpful, and my database to kick me in the ass whenever I get sloppy.
No indexes (Score:2)
Since Mysql is "helpful" and converts every column value from string to a number, there's no chance in hell it'll use indexes to do the lookup.
The way you fix it in the query is by using quotes around the literal value.
But Mysql should do the proper thing and that is, IMnsHO, to convert the user data to the column type, and then do the lookup.