dinmukhamedm commented on issue #2390:
URL: 
https://github.com/apache/datafusion-sqlparser-rs/issues/2390#issuecomment-4827525560

   Ok, this is slightly more complex, because ClickHouse is very permissive. 
Using the terminology from the linked PR, clickhouse allows both
   
   ```sql
   SELECT INTERVAL '1 day'; -- PostgreSQL like syntax
   ```
   
   and
   
   ```sql
   SELECT INTERVAL 2 DAY; -- MySQL-like syntax
   ```
   
   The latter approach to parsing is more flexible, allowing the expression 
between `INTERVAL` and `DAY` qualifier to be anything ranging from a single 
number to an arithmetic expression `INTERVAL 1 + 1 DAY` to a column reference 
like `INTERVAL user_id DAY`.
   
   The former is strict, and even if a dialect allows unquoted intervals (by 
the way postgres itself doesn't, while `sqlparser` sort of assumes it does?), 
it will only allow a single numeric expression to be the value.
   
   Now the original PR assumed that these two are coupled, i.e. it assumed that 
if a dialect allows intervals in string literals, then it does not allow 
complex expressions in interval values. That's not the case for ClickHouse. It 
looks like their parser acts "MySQL-like" for unquoted intervals, and 
"PostgreSQL-like" for quoted ones.
   
   Suggestion: we should split these two controls into 2 separate dialect-level 
flags, e.g. `require_interval_qualifier` (probably should have been called 
something like `supports_string_literal_intervals`) and 
`supports_complex_interval_expression`.
   
   I am happy to submit a pull request myself, but it might take a little more 
time, as I don't want the change to be breaking, and I am not very well 
familiar with other dialects.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to