-
Notifications
You must be signed in to change notification settings - Fork 38
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
feat(ibis): use the default input dialect #962
feat(ibis): use the default input dialect #962
Conversation
ibis-server/app/mdl/rewriter.py
Outdated
def _transpile(self, planned_sql: str) -> str: | ||
write = self._get_write_dialect(self.data_source) | ||
return sqlglot.transpile(planned_sql, read="trino", write=write)[0] | ||
return sqlglot.transpile(planned_sql, write=write)[0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method is used for v2 and v3. For v2, the read dialect is trino
. How about splitting this method for each class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, do we not receive the statements with the trino dialect? I'm not sure. If the input statement of v2 is already not trino dialect, your way is right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm.. No, maybe you're right. We're better to split v2 and v3 because the trino dialect also handles the functions converting between trino and others data source ( Currently, the v2 function white list used by AI service is based on the trion function) 🤔
The BigQuery CI has issues. I tested BigQuery in my local environment and all pass.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description
Close #930
The root cause of #930 is the
trino
dialect has a specific limit for the date_add function. We can't use it as a normal scalar function. We should follow the spec of trino doc.However, we want a common SQL base for some general purpose. I think we can change the input dialect to the default dialect which has fewer limitations for the function usage.
However, the output for the BigQuery is still wrong.
INTERVAL (INTERVAL '1' DAY) DAY)
isn't a valid SQL for BigQuery. It seems SQLGlot has some specific definition for thedate_add
function. The SQL should beIt's different from the original definition of BigQuery
Additional Changed
date_add
definition for bigqueryinstr
for MySQLinstr
is an alias ofstrpos
in DataFusion, the inputinstr
function will be transformed tostrpos
, then the sqlglot can't transpilestrpos
toinstr
when using the default dialect tomysql
dialect`. We need to file another issue for it.