[Qgis-developer] QgsExpression: replacement for QgsSearchString

Martin Dobias wonder.sk at gmail.com
Sat Aug 27 17:52:11 EDT 2011


On Sat, Aug 27, 2011 at 11:06 PM, Mayeul Kauffmann
<mayeul.kauffmann at free.fr> 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


More information about the Qgis-developer mailing list