feat: support datetime_field as expr for bigquery#1971
feat: support datetime_field as expr for bigquery#1971chenkovsky wants to merge 1 commit intoapache:mainfrom
Conversation
| let stmt = bigquery().verified_stmt(concat!( | ||
| "SELECT ", | ||
| "DATE_TRUNC(CURRENT_DATE, DAY), ", | ||
| "DATE_TRUNC(CURRENT_DATE, WEEK(MONDAY)) ", | ||
| "FROM my_table", | ||
| )); |
There was a problem hiding this comment.
double checking the intent of the changes: my understanding is that currently given SELECT DATE_TRUNC(CURRENT_DATE, WEEK(MONDAY), WEEK(MONDAY) should be parsed as a function with name WEEK and having a single identifier MONDAY as argument? Is that indeed the case (vs e.g the parser not being able to handle such a statement)
There was a problem hiding this comment.
currently, DAY will be parsed as ident, week will be parsed as function. I think this is flawed.
- when transpiling bigquery sql to another dialect,
DATE_TRUNC(CURRENT_DATE, DAY)should be transpiled toDATE_TRUNC(CURRENT_DATE,'day'), but currently, it will be transpiled intoDATE_TRUNC(CURRENT_DATE, DAY). - when compiling sql to logical plan, planner will try to find column called DAY, MONDAY, and function called WEEK. we should tell planner this is not function or column. I think we should convert it into str when planning.
There was a problem hiding this comment.
Ah I see, I think the current behavior of having it parsed as a function is preferable since the construct is syntatically a function - there's quite a lot of such special scenarios across dialects and it would likely be unwieldy to cover them consistently and I think out of scope for the parser as well
There was a problem hiding this comment.
thanks. if it's out of scope， i will close this pr. it can also be solved with a postprocessor.
2 participants
bigquery supports
WEEK(MONDAY)should be parsed to datetime_field