parser (postgres): wrong operator precedence #8661

Activity

1. ansh-rohilla commented on Oct 17, 2026

   

   ansh-rohilla

   on Oct 17, 2026

   Last edited by ansh-rohilla

   Contributor

   More actions

   I investigated this issue and put together a fix for the operator precedence:

   Root Cause

   In standard SQL and PostgreSQL operator precedence, comparison operators (=, !=, <>, <, >, <=, >=) have higher precedence than IS, IS NOT, ISNULL, and NOTNULL.
   In SQLGlot, IS was previously registered in RANGE_PARSERS under _parse_range(), which sits underneath _parse_comparison() and _parse_equality(). Consequently, in an expression like t.a = t.b IS NULL, t.b IS NULL was evaluated first as the right-hand operand of =.

   Solution

   • Introduced _parse_is_predicate() in the parser between conjunctions (AND) and equality/comparison (_parse_equality()), and removed IS from RANGE_PARSERS.
   • Added test coverage in tests/test_parser.py (test_is_precedence) and PostgreSQL dialect identity tests in tests/dialects/test_postgres.py.
   • Verified that all dialect and parser tests pass without regressions.

   Branch & Commit

   • Branch: https://github.com/ansh-rohilla/sqlglot/tree/fix/postgres-operator-precedence-8661
   • Commit: ansh-rohilla@d26b6cb
   • Compare view: https://github.com/tobymao/sqlglot/compare/main...ansh-rohilla:sqlglot:fix/postgres-operator-precedence-8661?expand=1
2. hafizahmedzia commented on Oct 17, 2026

   

   hafizahmedzia

   on Oct 17, 2026

   More actions

   I checked an additional consequence through simplify, using PostgreSQL 18.6 via PGlite 0.5.10 as the execution oracle. On main b50e43e4:

   from sqlglot import parse_one
   from sqlglot.optimizer.simplify import simplify
   
   print(simplify(parse_one("SELECT NULL = NULL IS NULL", read="postgres")).sql("postgres"))
   # SELECT NULL = TRUE

   PostgreSQL returns TRUE for the source and NULL for that output. SELECT FALSE = FALSE IS NULL similarly changes from FALSE to TRUE after simplification. Explicit (a = b) IS NULL and a = (b IS NULL) controls preserved their respective meanings.

   I also checked the existing fix by @ansh-rohilla at d26b6cbb: those examples preserve their results there; its parent ca870e84 reproduces the failures. Across seven comparison operators, four null-predicate spellings, and explicit left/right parentheses, all 84 expression forms matched PostgreSQL over the nine TRUE/FALSE/NULL operand combinations; tested main and the fix's parent disagreed on the 28 unparenthesized forms. For the AST check I explicitly parenthesized the parsed tree, since unchanged round-trip text can mask the grouping error.

   This is independent semantic validation of the existing fix, not another implementation. Python 3.12.14; PostgreSQL oracle was the WASM build, not a native server.