All of queries should return correct result even if including large number

[kamipo]

Currently several queries cannot return correct result due to incorrect
RangeError handling.

First example:

assert_equal true, Topic.where(id: [1, 9223372036854775808]).exists?
assert_equal true, Topic.where.not(id: 9223372036854775808).exists?

The first example is obviously to be true, but currently it returns
false.

Second example:

assert_equal topics(:first), Topic.where(id: 1..9223372036854775808).find(1)

The second example also should return the object, but currently it
raises RecordNotFound.

It can be seen from the examples, the queries including large number
assuming empty result is not always correct.

Therefore, This change handles RangeError to generate executable SQL
instead of raising RangeError to users to always return correct
result. By this change, it is no longer raised RangeError to users.

[matthewd]

Ugh... I'm sure I was worried about these sorts of cases when we added that rescue 😕

I don't think replacing binds with inline values is the solution, though. It provides a trivial means of blowing out the prepared statement cache, and even in the best case gives a surprise inefficient query.. what was an index lookup is now a full table scan.

If we can't pick out just the known cases, like find(hugenum), I think we have to just let the exception raise.

[kamipo]

I changed the implementation to build "1=0" predicate rather than replacing binds with inline values. I think it is no longer given inefficient query.

[rafaelfranca]

I'm thing this new implementation is good. @matthewd do you still have concerns?

[sgrif]

build_query_attribute appears to be doing something really implicit. I'd like to see it be made much more explicit, but this seems fine to me overall. The additional test cases make sense.

I would like to see the intent of build_query_attribute made more clear before this is merged though

[matthewd]

This still opens the possibility of 2**N query cache entries for a single query with N integer parameters, but that's far more bounded than infinity. And it avoids wasting database effort on the known-false condition, so that's good.

I agree the current rescues are catching too much, so something must change. If this can fix it while avoiding even more exceptions, so much the better.

[rafaelfranca]

What Topic.where(id: [1, 9223372036854775808]).to_a would do? Raise an exception or return an empty array? I feel if it return an empty array it will be really hard to track down that your query is not returning any object because one or more of the ids you passed are too big.

[rafaelfranca]

Sounds good to me, but let's wait @matthewd's approval

[kamipo]

In this PR, finder methods no longer raise RangeError.
So StatementCache#execute is the only place to raise the exception for finder queries.

#29988 closely related with this PR to avoid catching the exception in much places.
Thus I cherry-picked #29988 in this PR.

[matthewd]

This rescue makes me nervous, just because it sounds far-reaching.

I agree it's fine to put it here in practice, because of the very limited set of statements that are eligible for this cache, as you noted in the commit message. I think that's worth a comment here too, though: both to hopefully draw attention if the cache ever gets used for other queries, and just to reassure future readers me next time I read through this code 😅

[kamipo]

I'd be going to merge this PR since I think I've addressed all suggestions, and this PR already got two approvals and the intent of the code is clear enough.

Let me know if anyone has any suggestions, I think I could address that before the final 6.0 release.

cc @rafaelfranca @matthewd

[rafaelfranca]