[substrait] [sqllogictest] Operator precedence in SQL parsing

[hsiang-c]

Describe the bug

We tried to test a few arithmetic overflow cases in sqllogictest and found that :: has higher precedence over minus sign (-).

To Reproduce

> select -128::tinyint;
Arrow error: Cast error: Can't cast value 128 to type Int8

> select (-128)::tinyint;
+-------------+
| Int64(-128) |
+-------------+
| -128        |
+-------------+
1 row(s) fetched.
Elapsed 0.003 seconds.

Expected behavior

> select -128::tinyint;
+-------------+
| Int64(-128) |
+-------------+
| -128        |
+-------------+

Additional context

No response

[kumarUjjawal]

• Our SQL parser (via sqlparser-rs) thinks :: has higher precedence than unary -. So -128::tinyint is parsed as “negate (cast 128 to tinyint)” instead of “cast (-128)
  to tinyint”.
• DataFusion keeps that shape: it builds NEGATE(CAST(128 AS INT8)). Arrow runs the cast first, sees 128 doesn’t fit into INT8, and errors out before negation happens.
• With parentheses ((-128)::tinyint) the negative literal is produced before the cast, so we end up casting -128, which works.

Any query with -::<narrow_int_type> where the positive literal is out of range (tinyint, smallint, etc.) will fail even though the negative value is valid.

We have two options:

1. Change precedence in sqlparser-rs (treat unary - as higher than ::), or
   2.. Keep the parser as-is but add a rewrite in DataFusion’s SQL layer so -(::type) becomes ( -)::type

[Omega359]

https://www.postgresql.org/docs/18/sql-syntax-lexical.html#SQL-PRECEDENCE shows postgresql's precedence ordering.

That has :: as having higher precedence than - which to me seems logical.

[hsiang-c]

Thanks @kumarUjjawal and @Omega359 for your reply, I think it makes sense to keep the current behavior.