You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Lai Zhou (JIRA)" <ji...@apache.org> on 2019/05/15 10:51:00 UTC
[jira] [Updated] (CALCITE-3069) Make the JDBC Connection more
extensible like the FrameworkConfig API
[ https://issues.apache.org/jira/browse/CALCITE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lai Zhou updated CALCITE-3069:
------------------------------
Description:
More and more users are interested in building custom sql engines on top of Calcite.
But for different sql engines, there're differences on sql parsing, expression conversions, implicit type casting ...even the physical implementations for logical plan.
I think the FrameworkConfig API now provided a better way than JDBC Connection to custom these things.Are there any plans in the roadmap to enhance the JDBC Connection config , like FrameworkConfig API , to improve Calcite's extensibility ?
Otherwise, implementing the whole physical plan like the default Enumerable-implementation will be boring , that also require a lot of work. May be we can do something to make the physical and execution plan(that says code-gen ) more customizable.
Are there any thoughts on this issue?
was:
More and more users are interested in building custom sql engines on top of Calcite.
But for different sql engines, there're differences on sql parsing, expression conversions, implicit type casting ...even the physical implementations for logical plan.
I think the FrameworkConfig API now provided a better way than JDBC Connection to custom these things.Are there any plans in the roadmap to enhance the JDBC Connection config , like FrameworkConfig API , to improve Calcite's extensibility ?
Otherwise, implementing the whole physical plan like the default Enumerable-implementation will be boring , that also require a lot of work. May be we can do something to make the physical and execution plan(that says code-gen ) more customizable.
Are there any thoughts on this issue?
* customizable
* customizable
> Make the JDBC Connection more extensible like the FrameworkConfig API
> ---------------------------------------------------------------------
>
> Key: CALCITE-3069
> URL: https://issues.apache.org/jira/browse/CALCITE-3069
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.19.0
> Reporter: Lai Zhou
> Priority: Major
>
> More and more users are interested in building custom sql engines on top of Calcite.
> But for different sql engines, there're differences on sql parsing, expression conversions, implicit type casting ...even the physical implementations for logical plan.
> I think the FrameworkConfig API now provided a better way than JDBC Connection to custom these things.Are there any plans in the roadmap to enhance the JDBC Connection config , like FrameworkConfig API , to improve Calcite's extensibility ?
> Otherwise, implementing the whole physical plan like the default Enumerable-implementation will be boring , that also require a lot of work. May be we can do something to make the physical and execution plan(that says code-gen ) more customizable.
> Are there any thoughts on this issue?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)