[
https://issues.apache.org/jira/browse/CALCITE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16109791#comment-16109791
]
Julian Hyde commented on CALCITE-1913:
--------------------------------------
Horses for courses, as they say. It depends.
For {{FETCH}}, I would add a method to {{SqlDialect}}. In fact it is a perfect
example of that. One indication of this is that the method can be concisely
described in javadoc. The application shouldn't have to worry about versions,
just capabilities.
Regarding {{JdbcRules}}. Determining what can be pushed down is extremely
complicated. Not just based on {{SqlKind}}, or {{SqlOperator}}, but sometimes
based on the types of the arguments to the operator. I wouldn't attempt to
apply to the same policy to that as to SQL generation.
Regarding n-ary {{CONCAT}}. This does seem a case for adding version as a
protected field (with no accessor method) in {{SqlDialect}}.
Note that {{static DatabaseProduct SqlDialect.getProduct(String productName,
String productVersion)}} has a {{productVersion}} argument (not used). So we
could even include version in {{DatabaseProduct}}. But we'd have to live with
the consequences.
> 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)
