Skip to content

CEIL and FLOOR do not support comma syntax #1376

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
seve-martinez opened this issue Aug 11, 2024 · 2 comments · Fixed by #1377
Closed

CEIL and FLOOR do not support comma syntax #1376

seve-martinez opened this issue Aug 11, 2024 · 2 comments · Fixed by #1377

Comments

@seve-martinez
Copy link
Contributor

The current implementation only supports CEIL/FLOOR calls when including TO <DateTimeField>. However this syntax appears to be rare and so far I've only found it supported in Kinesis, which isn't supported by sqlparser at all.

The majority of dialects support a single expression, or an expression and a scale separated by a comma:

SELECT CEIL(321.56, 1)

-- prints 321.6

SELECT CEIL(321.56)
-- prints 322

Snowflake
BigQuery
Hive
ClickHouse
DuckDb
MsSql
MySql
Postgres
Redshift
SQLite

The existing impl:
https://github.com/sqlparser-rs/sqlparser-rs/blob/1e209d87415a5adfedccac8cee3e2860122e4acb/src/parser/mod.rs#L1694-L1716

Because the CEIL/FLOOR expressions expect a DateTimeField, I'm not sure it makes sense to just pass a numeric literal to this and force into a Custom(Ident) type.

Happy to open a PR for this, but wanted to understand the best way to handle field attribute here.

@git-hulk
Copy link
Member

I think a better way is to change the field to an enum like:

{
   to_datetime: DateTimeField,
   precision: Number,
}

But this would also have a slight behavior change on Floor/Ceil expression.

@iffyio What do you think about this?

@iffyio
Copy link
Contributor

iffyio commented Aug 12, 2024

Oh that's interesting, I think its a bit strange for the parser to support the CEIL(x TO y) syntax given none of the supported dialects do, looking at the PR discussion it seems it was intentional at the time at least (not sure if its still valid since then) so we could just as well preserve the current syntax.

Yeah I think representing the extra argument as an enum, merging it with the datetime sounds reasonable!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants