bziobrowski commented on PR #14238:
URL: https://github.com/apache/pinot/pull/14238#issuecomment-2427003830
Yes, calcite's babel parser has the same issue (core parser is better). It
comes mainly from using nonReservedKeywords and `fixing it` with lookahead=2
setting, not from babel sql con
gortiz commented on PR #14238:
URL: https://github.com/apache/pinot/pull/14238#issuecomment-2426191164
I've just verified this is an issue for Calcite as well. I've executed
`sqlline` as specified in https://calcite.apache.org/docs/tutorial.html and
then I've queried `SELECT * FROM emps as
gortiz commented on PR #14238:
URL: https://github.com/apache/pinot/pull/14238#issuecomment-2426176761
Given we use a slightly modified version of Apache Calcite parser... is it
safe to assume the standard Apache Calcite parser has this issue as well? If
that is the case I think we should a
bziobrowski commented on PR #14238:
URL: https://github.com/apache/pinot/pull/14238#issuecomment-2416406811
I don't think this problem can be addressed with better documentation
because errors returned by parsers have:
A. wrong position
B. point to wrong token
C. suggest empty list
Jackie-Jiang commented on PR #14238:
URL: https://github.com/apache/pinot/pull/14238#issuecomment-2414801502
If babel is the root cause, we can consider using a different config to
reduce the non-preserved keyword
--
This is an automated message from the Apache Git Service.
To respond to
Jackie-Jiang commented on PR #14238:
URL: https://github.com/apache/pinot/pull/14238#issuecomment-2414798159
We should avoid touching the code copy-pasted from Calcite unless absolutely
necessary. Modifying the copy pasted code means extra management overhead going
forward, which IMO is not
codecov-commenter commented on PR #14238:
URL: https://github.com/apache/pinot/pull/14238#issuecomment-2413586966
##
[Codecov](https://app.codecov.io/gh/apache/pinot/pull/14238?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&u
bziobrowski opened a new pull request, #14238:
URL: https://github.com/apache/pinot/pull/14238
Work in progress
Currently if we use any reserved keyword as part of query or as a column
name in Pinot, we get back a very cryptic(non-useful) Query Compilation error,
e.g.
```sql
