[
https://issues.apache.org/jira/browse/CALCITE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841608#comment-16841608
]
Stamatis Zampetakis commented on CALCITE-3069:
----------------------------------------------
I'm more with [~zhztheplayer] in this. It makes more sense to try to make JDBC
APIs call Framework/Planner than the opposite.
I'm not sure what you would like to make configurable in JDBC connection. The
way I read the description it seems that what you need is already done by the
FrameworkConfig API. It would help if you had some concrete examples of what
you want to achieve. Moreover, I don't understand well what you mean in the
last paragraph. It would help if you could clarify a bit.
> 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)
