Thanks @Julian. I have opened the PR.
https://github.com/apache/calcite/pull/446
Best,
SunJincheng
2017-05-10 5:46 GMT+08:00 Julian Hyde :
> Thanks. I’ve assigned it to you.
>
> > On May 9, 2017, at 1:43 AM, jincheng sun
> wrote:
> >
> > Hi Julian,
> > Thanks for your reply. I had created a
I'm a bit closer with this, but it's still not quite working.
Couple of things I've noticed:
* literal() cannot be called with an enum
* the time unit is the first operand to extract when looking at testExtract
through the debugger
This seems a bit closer:
builder.call(SqlStdOperatorTable.EXTRACT
I am trying to "separate" certain subsets of Operators in a query tree and
transform them to a more "general" RelNode implementation, that holds the
information required to rebuild them. I want to implement something more
general than CALC (for more types of operators), that works like this:
Opera
Hi guys,
I am doing some work that might need the latest view matching rule as
described in https://issues.apache.org/jira/browse/CALCITE-1731
Just wondering if there is a nightly build of 1.13.0 available for
download.
If there's no nightly build available, could you please let me know when
will
Sergiy Simonov created CALCITE-1786:
---
Summary: Implement Oracle <12g support of limit/offset query syntax
Key: CALCITE-1786
URL: https://issues.apache.org/jira/browse/CALCITE-1786
Project: Calcite
We should have regular snapshot builds published that you can use for
testing purposes. Any time our build server successfully builds/tests
Calcite across JDK 7/8/9, a new snapshot will be promoted.
This is likely as simple as specifying a version of 1.13.0-SNAPSHOT in your
dependency management.
+1 to a release in the May timeframe. I'd be happy to volunteer to RM
(since I expect some rough edges on the coattails of the git repo
separation).
May will also be busy for me, so I am happy to defer to someone else :). I
just wanted to warn that this release probably won't be as smooth as those
Zain Humayun created CALCITE-1787:
-
Summary: thetaSketch Support for Druid Adapter
Key: CALCITE-1787
URL: https://issues.apache.org/jira/browse/CALCITE-1787
Project: Calcite
Issue Type: New F
Hi Hao,
It would be great if you can test the rule for your use-case and provide
some feedback. Let me know if I can help.
FWIW, I still plan to make a couple of improvements shortly, e.g., produce
rewritings containing union, hopefully before releasing 1.13.0.
--
Jesús
On 5/11/17, 3:37 PM, "
Calcite 1.13 will probably have to occur after Avatica 1.10, because
there are a couple of issues that require Avatica changes. (See the
dependencies of https://issues.apache.org/jira/browse/CALCITE-1612.)
Avatica is slated for "sometime in May", so Calcite 1.13 is probably
early June at the earli
Julian Hyde created CALCITE-1788:
Summary: Simplify handling of position in the parser
Key: CALCITE-1788
URL: https://issues.apache.org/jira/browse/CALCITE-1788
Project: Calcite
Issue Type: B
Julian Hyde created CALCITE-1789:
Summary: Wikipedia format change breaks file adapter test
Key: CALCITE-1789
URL: https://issues.apache.org/jira/browse/CALCITE-1789
Project: Calcite
Issue Ty
I'm not very sure.
I can imagine that there are cases where you might not wish to
increase the number of expressions (see example 1) and you might not
wish to push down expensive computations (see example 2 and 3).
Example 1. Given
Project(x + y, x - y, x * y, x / y, Filter(x < y, R))
it is n
It seems that "composite" operators crop up quite often. Having kept
the operators separate in older adapters like the Mongo adapter, I
took a different approach in Druid adapter, and I'm quite please with
it.
DruidQuery contains a "stack" of internal relational operators. They
are held in the fie
While
> builder.getRexBuilder().makeFlag(TimeUnitRange.YEAR),
is fine, but we should change RelBuilder to allow
> builder.literal(TimeUnitRange.YEAR),
A SqlOperator doesn't need a returnTypeInference if each RexCall to
the function always has it is always an explicit return type. The
underlying
15 matches
Mail list logo
