Just for the record, Calcite now will parse "-1" as unary "-" applied to
the numeric literal "1". [1]
[1]
https://github.com/apache/calcite/blob/c945b7f49b99538748c871557f6ac80957be2b6e/core/src/main/codegen/templates/Parser.jj#L3521-L3527
Julian Hyde 于2022年10月5日周三 23:47写道：
> Thanks for
Thanks for checking, Itiel.
The only other thing to check is whether “-1” is parsed as a single numeric
literal or as unary “-“ applied to the numeric literal “1”. I don’t recall what
Calcite does.
> On Oct 5, 2022, at 3:43 AM, Itiel Sadeh wrote:
>
> From the following operator precedence
>From the following operator precedence table:
https://www.postgresql.org/docs/14/sql-syntax-lexical.html#SQL-PRECEDENCE ,
it looks like Calcite is consistent with Postgresql.
Thanks for the response.
On Wed, Oct 5, 2022 at 6:52 AM Julian Hyde wrote:
> Infix cast comes from Postgres. Can
Infix cast comes from Postgres. Can someone find a table of operator precedence
in Postgres? Perhaps write a test case involving operators with slightly higher
and lower precedence, so we can check that Calcite is consistent.
> On Oct 4, 2022, at 10:20 AM, Itiel Sadeh
> wrote:
>
> Hello,
>
Hello,
I've encountered weird parsing of infix cast with the babel parser, where
given the
following query:
SELECT -1 :: INT FROM t;
It will parse it as
UNARY_MINUS( CAST( 1 AS INT )),
while i've expected it to be
CAST(-1 AS INT)
As i've looked at the code I saw that the precedence of the
