You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It all boils down to what this library is really intended to do.
The number 1 concern is to have consistent behavior across all supported databases, as long as the unified library is used to build the queries and expressions.
Given databases A and B, we have the following scenarios,
A and B have the function
Both have the same behavior
This is a no-brainer; add it to the unified library
Both have different behavior
This is the problem double.mul(), double.sub(), etc. have
Force A to have B's behaviour?
Force B to have A's behaviour?
Give both different names and emulate both?
Don't add it at all?
Would users usually expect the behavior of A or B?
A has the function, B does not
It is easy to emulate in B with built-ins
Emulate it
It is hard to emulate in B with built-ins
Might be worth it to emulate
It is impossible to emulate in B with built-ins
Do we have other "easy" mechanisms of emulation? (User-defined functions in SQLite)
Right now, double.mul() and double.sub() have
number|null
for the return type.This only happens because of SQLite.
1e999 * 0e0
isnull
on SQLite.1e999 - 1e999
isnull
on SQLite.You can't even use
Infinity
in other databases; so, we don't get these problems.It would be nice if we made
mul()/sub()
just returnnumber
.In SQLite, this would be emulated with
COALESCE(x * y, (SELECT SUM(9223372036854775807) FROM (SELECT NULL UNION ALL SELECT NULL)))
Or,
throwIfNull(x * y)
The text was updated successfully, but these errors were encountered: