You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Christian Beikov (JIRA)" <ji...@apache.org> on 2017/09/07 17:28:00 UTC

[jira] [Commented] (CALCITE-1913) Include DB version in SqlDialect

    [ https://issues.apache.org/jira/browse/CALCITE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16157280#comment-16157280 ] 

Christian Beikov commented on CALCITE-1913:
-------------------------------------------

I implemented part of what you describe as part of a PR that adds sequence support. Maybe you could comment on that? [~jbalint@gmail.com]
https://github.com/apache/calcite/pull/514

By allowing a user to provide a custom SqlDialectFactory, a user could make use of a custom dialect implementation. That way, a consumer of calcite can overrule if a feature is used or not. Still, the default implementation can make a decision about whether a feature is used by doing version comparisons. That obviously requires that SqlDialect is the "gate-keeper" to what a dialect actually supports rather than handling that through checks against DatabaseProduct.
My prime example for when the DatabaseProduct approach will break is MySQL. With version 8 it will support CTEs thus we could push down such SQL, yet we only have a single MYSQL enum entry. We could introduce multiple entries for respective versions(e.g. MYSQL5, MYSQL8) to handle such cases, but that won't handle cases where a user might not want to use a specific feature.

Allowing SqlDialect to handle unparsing or return whether a DBMS has a specific capability also allows for adding new dialects that don't fit into the current DatabaseProduct scheme. What if there is a MySQL fork out there that doesn't support feature X,Y,Z of our "standard MySQL" version we defined through a DatabaseProduct? These people would be out of luck right now.

Maybe you ([~julianhyde]) could comment further about what he doesn't like about this approach so we could tackle specifics?

> Include DB version in SqlDialect
> --------------------------------
>
>                 Key: CALCITE-1913
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1913
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.13.0
>            Reporter: Jess Balint
>            Assignee: Jess Balint
>            Priority: Minor
>
> It would be useful to have the DB version # in the SqlDialect for unparsing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)