Use the % operator instead of MOD() in SQLite

[derrabus]

Q	A
Type	improvement
Fixed issues	Part of #5745

Summary

Depending on the SQLite version and compile flags, SQLite might not have a MOD() function. Currently, we polyfill it.

However, SQLite does have a % operator that should always be available. This PR alters getModExpression() so that we use the operator instead of calling MOD(). We're doing the same thing for SQL Server already.

The operation is covered by the functional test ModExpressionTest which still passes.

[morozov]

Should this patch also add a runtime deprecation to the implementation of the MOD() UDF? Or it's undesired because even once we remove it, the native implementation may still be available?

[derrabus]

Or it's undesired because even once we remove it, the native implementation may still be available?

That's what I was asking in #5745 (comment). Calling MOD() is not wrong because SQLite does provide a native implementation, so triggering a deprecation might be confusing as long as we don't provide a way to opt out of our polyfill.

[VincentLanglet]

Hi, I just wanted to report that previously, code like

SELECT MOD(10, NULLIF(m.intColumn, m.intColumn))
FROM QueryResult\Entities\Many m

could throw a Modulo by zero and after this PR there is no exception anymore.

Not sure if it should be considered as a "bugfix" or a "bc break".

I just discovered this while trying to solve phpstan/phpstan-doctrine tests.

[derrabus]

That exception should never have leaked to userland in the first place, I believe. The behavior that we now have should be more consistent with other drivers.