Parsing large numbers is inconsistent

[alex-spies]

Elasticsearch Version

main

Installed Plugins

No response

Java Version

17

OS Version

Ubuntu 23.04

Problem Description

• Evaluating the query row a=0 | EVAL b=1 > -9223372036854775809 returns

  {"error":{"root_cause":[{"type":"arithmetic_exception","reason":"BigInteger out of long 
  range"}],"type":"arithmetic_exception","reason":"BigInteger out of long range"},"status":500}
  

  This should at least return a 400.

• row a=0 | EVAL b=1 > 9223372036854775809 returns

  {"error":{"root_cause":[{"type":"verification_exception","reason":"Found 1 problem\nline 1:18: first argument of [1 > 9223372036854775809] is [integer] and second is [unsigned_long]. [unsigned_long] can only be operated on together with another [unsigned_long]"}],
  "type":"verification_exception","reason":"Found 1 problem\nline 1:18: first argument of [1 > 9223372036854775809] is [integer] and second is [unsigned_long]. [unsigned_long] can only be operated on together with another [unsigned_long]"},"status":400}
  

  This is generally correct, but it's unexpected given that the following query runs fine:
  row a=0 | EVAL b=1 > 92233720368547758090 (just add a 0 at the end).

  Maybe we should not cast literals to unsigned long, unless the user explicitly writes to_ul(...)?

Steps to Reproduce

See above.

Logs (if relevant)

No response

[elasticsearchmachine]

Pinging @elastic/es-analytics-geo (Team:Analytics)

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[not-napoleon]

I've opened #110663 to address the second bullet. I think the cast is okay for now, but we really should get around to supporting mixed operations on unsigned longs soon. That particular one is pretty easy. I'm working on a PR to fix the first bullet, should be up shortly.