[Qgis-developer] QgsExpression: replacement for QgsSearchString

[Martin Dobias]

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