[
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)