[
https://issues.apache.org/jira/browse/CALCITE-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820901#comment-17820901
]
Guillaume Massé edited comment on CALCITE-6281 at 2/26/24 11:09 PM:
--------------------------------------------------------------------
What's the scope of this ticket. What are the properties we want to be
consistent with?
parsing? both calcite & dialect X can accept this expression(How can we make
sure they have equivalent structure, When they fail, can we compare their
syntax error)
validation? both can validate this expression (If they validate, how can we
compare they have similar logical plans?)
un-parsing (RelToSqlNode ?) if we un-parse an expression, is it valid to parse
in dialect X ?
runtime? If we run this logical plan, does it produce the same result when
database X runs it ?
was (Author: masseguillaume):
What's the scope of this ticket. What are the properties we want to be
consistent with?
parsing? both calcite & dialect X can accept this expression(How can we make
sure they have equivalent structure, When they fail, can we compare their
syntax error)
validation? both can validate this expression
un-parsing (RelToSqlNode ?) if we un-parse an expression, is it valid to parse
in dialect X ?
runtime? If we run this logical plan, does it produce the same result when
database X runs it ?
> Add test infrastructure to ensure that Calcite is consistent with the SQL
> dialects it is trying to emulate
> ----------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-6281
> URL: https://issues.apache.org/jira/browse/CALCITE-6281
> Project: Calcite
> Issue Type: Improvement
> Reporter: Julian Hyde
> Priority: Major
>
> Add test infrastructure to ensure that Calcite is consistent with the SQL
> dialects it is trying to emulate.
> Calcite is able to emulate other SQL dialects. For example, it can pretend to
> be MySQL by setting "lib=mysql, lex=mysql, conformance=mysql_5". In that
> mode, the user would expect there to be a SUBSTR function, and that
> {{SUBSTR('abc' FROM 0)}} would [return the empty string, the same as
> MySQL|https://github.com/apache/calcite/blob/022d878a73dec796bb72743804a6dded7c239bd3/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L9428].
> (On Postgres, the same expression returns 'abc'.)
> How do we trust that MySQL does indeed have that behavior? How do we find out
> if, in a later release, the MySQL team decides to change the behavior. That
> is the goal of this case.
> We propose to add tests that run expressions on both MySQL and
> Calcite-pretending-to-be-MySQL, and ensure that the result is the same on
> both. We use
> [testContainers|https://github.com/testcontainers/testcontainers-java] to
> instantiate, via Docker, and instance of MySQL.
> See discussion [Ensuring that Calcite is consistent with other SQL
> systems|https://lists.apache.org/thread/mxy9p6cy8sssf1sq3gz7zkzm6hsysns5].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)