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

Jess Balint commented on CALCITE-1913:
--------------------------------------

People may choose not to use a feature if it's buggy? This would mean dialects 
are not only a reflection of the SQL dialect, but also user preferences?

So let's look at some examples here.

First, we see {{JdbcRules}} maintaining two sets of aggregates:
{code:java}
  static final ImmutableList<SqlKind> AGG_FUNCS;
  static final ImmutableList<SqlKind> MYSQL_AGG_FUNCS;
{code}

and choosing between these based on DB product:
{code:java}
    switch (sqlDialect.getDatabaseProduct()) {
    case MYSQL:
      return MYSQL_AGG_FUNCS.contains(aggregation.getKind());
    default:
      return AGG_FUNCS.contains(aggregation.getKind());
    }
{code}

Sure, we can encapsulate the set of aggregate functions behind the 
{{SqlDialect}} API and a add a subclass for MySQL (version-independent). Would 
it make sense here? I don't have a preference.

Something like {{SqlImplementor.rewriteSingleValueExpr()}} uses:
{code:java}
    switch (sqlDialect.getDatabaseProduct()) {
    case MYSQL:
    case HSQLDB:
{code}

here, we can encapsulate this with either a {{boolean 
supportsSingleValueRewrite()}} method or adding {{rewriteSingleValueExpr()}} to 
the dialect.

However, in my application, I have something very similar to test for support 
of {{FETCH}}. SQL Server 2008 doesn't support it. I can either ask for the 
version from the dialect:
{code:java}
                switch (dialect.getDatabaseProduct()) {
                        case MSSQL:
                                return dialect.getDatabaseMajorVersion() >= 11;
{code}
or add a new method to {{SqlDialect}} such as {{supportsFetch()}} (with 
different semantics than the current {{supportsOffsetFetch()}})). Version is 
also required when deciding how to translate functions, e.g. SQL Server 2012 
supports n-ary {{CONCAT()}} but SQL Server 2008 needs to use {{+}}. If 
{{SqlDialect}} doesn't expose version, then what? Add {{supportsNaryConcat()}} 
or have each dialect maintain it's own operator table?

> 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
>             Fix For: 1.14.0
>
>
> 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)

Reply via email to