[
https://issues.apache.org/jira/browse/CALCITE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-3416.
---------------------------------
Fix Version/s: 1.22.0
Resolution: Fixed
Fixed in
[ff43dcb|https://github.com/apache/calcite/commit/ff43dcb95caa251e5fc8120980fc70c8fea8ac40]
!
> SQL Dialects "DEFAULT"s should be more extensible
> -------------------------------------------------
>
> Key: CALCITE-3416
> URL: https://issues.apache.org/jira/browse/CALCITE-3416
> Project: Calcite
> Issue Type: Improvement
> Reporter: Steven Talbot
> Assignee: Danny Chen
> Priority: Minor
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The behavior of SQLDialect is partly governed by the methods defined on the
> given dialect subclass and partly governed by options passed in in a Context
> object. So every dialect subclass exposes a "DEFAULT" instance that has been
> initialized with the correct Context.
> However, if you then wish to extend the dialect for one reason or another,
> you must create a new instance to extend, or of course create a whole new
> subclass. In either case, you lose the options from the Context passed into
> the default, which governs important behavior of the dialect. You can
> copy-paste the relevant Context out of the Calcite code, but then you lose
> future improvements or fixes that might land in mainline Calcite.
> It would be nice if each dialect exposed the DEFAULT_CONTEXT that it passed
> into its DEFAULT instance as a public final member. Then, when extending the
> dialect, you simply initialize your extension with the DEFAULT_CONTEXT, and
> if any customization needs to happens on the Context options that's easy to
> do with the Context's API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)