You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] JSQLParser Version : 5.1 RDBMS : PostgreSQL 10 mix the JSON and relational operators, it outputs the wrong AST and sql. #2163
BTW
if we parse the new sql SELECT * FROM t WHERE js#>>'{a,b,1}' <> 'bar'
JSQLParser will recognize it as a wrong Bitwise operation in the AST:
the collumn name is js#, and the operator is >>.
Verified on current master (a5765f3): select * from t where js #>> '{a,b,1}' <> 'bar' now parses with the expected precedence: the WHERE clause is NotEqualsTo(JsonExpression(js #>> '{a,b,1}'), 'bar'). The deparser output also keeps the spaces: SELECT * FROM t WHERE js #>> '{a,b,1}' <> 'bar'. Both reported errors are resolved. Can this be closed?
Activity
hijackworld commentedon Feb 11, 2025
BTW
if we parse the new sql
SELECT * FROM t WHERE js#>>'{a,b,1}' <> 'bar'JSQLParser will recognize it as a wrong Bitwise operation in the AST:
the collumn name is
js#, and the operator is>>.manticore-projects commentedon Feb 11, 2025
In this case you will need to quote the column name like
"js#"since it interferes with the JSON operator#>>.hijackworld commentedon Feb 11, 2025
thanks.
what about the issue of the wrong priority?
js #>> ('{a,b,1}' <> 'bar')in fact, what we need is:
(js #>> '{a,b,1}') <> 'bar', just like PG does.we parse the original sql by JSQLParser 4.9, and it works well.
it seems like a bug for version 5.1 .
manticore-projects commentedon Feb 11, 2025
Adding brackets for clarity may be your best instant solution.
fudianchn commentedon Aug 22, 2026
Verified on current master (
a5765f3):select * from t where js #>> '{a,b,1}' <> 'bar'now parses with the expected precedence: the WHERE clause isNotEqualsTo(JsonExpression(js #>> '{a,b,1}'), 'bar'). The deparser output also keeps the spaces:SELECT * FROM t WHERE js #>> '{a,b,1}' <> 'bar'. Both reported errors are resolved. Can this be closed?