Re: Type Inference and Nullability set/change

What Danny says is correct. Type inference is built into each operator/function, so if you want to customize type inference, you basically need to create a new set of operators/functions. I’ll add that there is interface RelDataTypeSystem, which allows you to customize properties of built-in

Re: Type Inference and Nullability set/change

Hi Danny, Thanks very much for quick response. Basically, you are saying that there are not ways to change type inference rules. The only way to do that is to write your own type inference functions for some specific calls, then use RexShuttle to re-do type inference. Dustin On Thu, Oct 24,

Re: Type Inference and Nullability set/change

Dustin ~ The type inference for all kinds of operator/functions are defined by 2 kinds of components in Calcite: • The SqlOperandTypeChecker infers the operands data types • The SqlReturnTypeInference infers the return data type of the call That means the type inference strategy is fixed and

Type Inference and Nullability set/change

Hi All, After I translate a query (SQL text) into a RelNode Tree like this, RelNode res = planner.getLogicalPlan(getSqlText()); What's the simplest way to do/change type inference and set nullability for all expressions in node res? It seems that RelNode has some type info already like below.

Re: Redirecting to https

Sounds cool, hope it works perfectly ! Best, Danny Chan 在 2019年10月25日 +0800 AM4:23，Julian Hyde ，写道： > Thanks for the suggestions. I’ve logged > https://issues.apache.org/jira/browse/CALCITE-3445 > . I’ll try to get to it, > but feel free to

Re: Re: [DISCUSS] On-demand traitset request

I have the same feeling, it seems to much interfaces for the physical node(we do not really have physical class for physical nodes yet), so these interfaces may just be put into the RelNode, that was too complex and to much for me, can we have a way that do not modify the nodes itself ? Best,

Re: [DISCUSSION] Extension of Metadata Query

I have created a JIRA issue https://issues.apache.org/jira/browse/CALCITE-3446  and start working ~ Best, Danny Chan 在 2019年10月25日 +0800 AM9:02，Julian Hyde ，写道： > Sure. > > Let’s have a test that creates such a sub-class. Then people can use it as an > example. > > Also, let’s make sure that a

[jira] [Created] (CALCITE-3446) Make RelMetadataQuery extendible

Danny Chen created CALCITE-3446: --- Summary: Make RelMetadataQuery extendible Key: CALCITE-3446 URL: https://issues.apache.org/jira/browse/CALCITE-3446 Project: Calcite Issue Type: Improvement

Re: [DISCUSSION] Extension of Metadata Query

Sure. Let’s have a test that creates such a sub-class. Then people can use it as an example. Also, let’s make sure that a sub-sub-class of RelMetadataQuery also works. Perhaps split RelMetadataQuery into a base class (containing the essential mechanism) and a derived class (containing the

Calcite-Master - Build # 1391 - Still Failing

The Apache Jenkins build system has built Calcite-Master (build #1391) Status: Still Failing Check console output at https://builds.apache.org/job/Calcite-Master/1391/ to view the results.

Re: Re: [DISCUSSION] Extension of Metadata Query

Sounds like we have reached a consensus, I guess. Can we create a JIRA to allow users to create their own sub-class of RelMetadataQuery? - Haisheng -- 发件人：Julian Hyde 日　期：2019年10月22日 09:58:34 收件人：dev 主　题：Re: [DISCUSSION] Extension

Calcite-Master - Build # 1390 - Still Failing

The Apache Jenkins build system has built Calcite-Master (build #1390) Status: Still Failing Check console output at https://builds.apache.org/job/Calcite-Master/1390/ to view the results.

Calcite-Master - Build # 1389 - Failure

The Apache Jenkins build system has built Calcite-Master (build #1389) Status: Failure Check console output at https://builds.apache.org/job/Calcite-Master/1389/ to view the results.

[jira] [Created] (CALCITE-3445) In web site, automatically redirect http to https

Julian Hyde created CALCITE-3445: Summary: In web site, automatically redirect http to https Key: CALCITE-3445 URL: https://issues.apache.org/jira/browse/CALCITE-3445 Project: Calcite Issue

Re: Redirecting to https

Thanks for the suggestions. I’ve logged https://issues.apache.org/jira/browse/CALCITE-3445 . I’ll try to get to it, but feel free to jump in. > On Oct 23, 2019, at 6:26 PM, Michael Mior wrote: > > Great! Seems like we could just take lines

[jira] [Created] (CALCITE-3444) Upgrade SQLLine to 1.9.0, and solve "Class path contains multiple SLF4J bindings" problem

Julian Hyde created CALCITE-3444: Summary: Upgrade SQLLine to 1.9.0, and solve "Class path contains multiple SLF4J bindings" problem Key: CALCITE-3444 URL: https://issues.apache.org/jira/browse/CALCITE-3444

[jira] [Created] (CALCITE-3443) Doesn't parse PreparedStatement successfully for there is placeholders in select area

huaicui created CALCITE-3443: Summary: Doesn't parse PreparedStatement successfully for there is placeholders in select area Key: CALCITE-3443 URL: https://issues.apache.org/jira/browse/CALCITE-3443

Re: Nested data handling in Caclite

Hello Naveen, 1. If I understand correctly, then yes you can extract nested fields from struct type. The syntax depends on StructKind value for your data type, for example for FULLY_QUALIFIED struct you should first make alias for your table and then request nested field like,

Nested data handling in Caclite

Hi, I work at Flipkart, we are using Calcite in our streaming platform. In most of our use cases, input data is nested. I understand Calcite flattens structs in scan and references fields positionally. I had a few questions on handling nested data - 1. Can RelNode DAG work with nested data

Re: [DISCUSS] State of the project 2019

Thanks a lot for your work Francis and +1 for Stamatis to be the next PMC chair ~ ~ Calcite is a great project and it offers as a strong SQL engine to help users to build data systems. My group uses Calcite to accelerate SQLs from multiple data engines by heuristic based, cost based and

Re: [DISCUSS] State of the project 2019

Hello, I have the impression too that Calcite is lesser known than other Apache projects, but this is not that surprising to me given the nature of the project itself, which requires in-depth knowledge of a rather complex topic, which makes it is less prone to a casual use and plug adoption. But

[jira] [Created] (CALCITE-3442) Set `stored_fields = _none` prohibit `FetchPhase` get be involved and improve the Performance for Elasticsearch

yunfeng created CALCITE-3442: Summary: Set `stored_fields = _none` prohibit `FetchPhase` get be involved and improve the Performance for Elasticsearch Key: CALCITE-3442 URL: