> It is not a "hack" because it does not work. It is what is called a "failed > attempt" at a hack.
Yeah, the ABS() hack does not work. Which led me to use `(SELECT SUM(9223372036854775807) FROM (SELECT NULL UNION ALL SELECT NULL))` which **does** work. > However, your assessment that coalesce is not "short-circuiting" is incorrect. > If x is not null, then x is returned and the constant expression is not > returned. > If the constant expression were a correlated expression, then it would not be > evaluated in the candidate context. > If x were null and the expression was not constant (and thus required > evaluation) > then it would be evaluated within the current context and its result returned. > > The documentation DOES NOT say that the arguments to coalesce will not be > evaluated, merely that the first one that is not-null will be returned. > > https://sqlite.org/lang_corefunc.html#coalesce You're right that the documentation doesn't say so. I did assume COALESCE() would always short-circuit because the SQL standard says COALESCE() is equivalent to CASE expressions. And I was pretty sure CASE expressions should always short-circuit. However, turns out, CASE expressions don't always short-circuit, either. They generally do short-circuit but there are edge cases where they don't. It isn't entirely intuitive to me what the conditions are, though. So, I guess I learned something new today. > > Something like THROW_IF_NULL(x) > > You could certainly write a function that did that. It would certainly be > better than a "hack" that does not even work. I'd rather keep the hack that does work than use a user-defined function, if I can help it. I feel like user-defined functions should be a last resort. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
