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 <[email protected]> 于2022年10月5日周三 23:47写道： > 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 <[email protected]> > wrote: > > > > 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 <[email protected]> > wrote: > > > >> 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 <[email protected] > > > >> wrote: > >>> > >>> 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 INFIX_CAST > is > >>> 94, and the precedence of the UNARY_MINUS is 80. > >>> > >>> Is there a reason for the INFIX_CAST's precedence to be that high? > Other > >>> binary operators such as BINARY_PLUS have precedence of 40. > >>> > >>> Thanks, > >>> > >>> Itiel > >> > >> > > -- Best, Benchao Li
