On Sat, Aug 27, 2011 at 11:06 PM, Mayeul Kauffmann <[email protected]> wrote: > >> > PostgreSQL is very strict about type conversions, Sqlite is not >> strict >> > at all and MySQL is somewhere in the middle. I have ended up with >> > these conversion rules: >> > - implicit conversions to desired types >> > - string->number conversions with invalid input return error >> > - arithmetic operators convert to numeric >> > - comparison with numeric type => numeric comparison > Apparently my email is too late as this is already merged. > Still, IMHO, I would suggest that your rule be as close as possible to > the existing rules of one major RDBMS (am I correct in assuming that > your implementation is close to MySQL?), or you even better you may use > the rule of one existing DB wrapper. > You will probably get more consistent/robust results by trying to follow > as much as possible an existing standard instead of inventing Yet > Another Conversion Standard. > There will be use cases that you have not thought about yet. In front of > them, the Qgis community would ask "how standard x solves this problem?" > instead of "should we use standard x, y or z for this particular case?" > > I am a big fan of postgres. But if you follow (say) MySQL 70 % of the > time, postgres 20 % of the time and your own rules the remaining 10%, I > would prefer if you try to use 100% MySQL-like rules.
Hi Mayeul the implicit conversion rules are generally the same as MySQL, with the exception that string that cannot be converted to a number triggers an error while in MySQL it "just" produces a warning. We are talking here about corner cases of implicit conversions where the SQL standard either does not define the behavior or the common RDBMS ignore that. Martin _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
