Julian Hyde created CALCITE-4389:
Summary: Calls to ROW and anonymous row operators sometimes print
too many spaces
Key: CALCITE-4389
URL: https://issues.apache.org/jira/browse/CALCITE-4389
Project:
-1 for the revert, we should fix the issues we encountered instead of
reverting the code brainless for a whole release.
At lease, project like Apache Flink has upgrade to version 1.26 and the
Sarg feature overall looks good.
We are trying to fix the Sarg issues in version 1.27 and we should
I agree with Danny.
I think we can use the parentheses to distinguish table vs. table-function
and use different namespaces for validation?
Bets,
Jark
On Tue, 3 Nov 2020 at 15:25, Danny Chan wrote:
> In current codebase, we actually never allows syntax like
>
> SELECT *
> FROM TT
>
>
Hi Stamatis,
Thank you for sharing this detailed information and appreciate your
excellent work as our chair.
It's an honor to be part of this awesome project. As we can see, we
have more and more people who are willing to contribute. But some of
them might do not know our convention. So the
Hi Stamatis,
Thanks for your great work.
2) What areas do we need to do better?
1. Lattice/Materialized view
2. Streaming(we can more contact with Flink project)
3) Which other candidates should we consider for PMC chair?
I think Haisheng and Danny are all excellent choices.
Regards!
Aron Tao
Hi Stamatis,
Thanks for your great work!
I am feeling lucky to have you as our chair in 2020!
Concerning the problem of PR reviewing, one method that comes to my mind is
to divide Calcite into a few sub-areas, and assign some owners to each
sub-area (based on code contribution, etc.). So once a
Stamatis>People who are responsible for upgrading Calcite, tend to follow
the dev
Stamatis>list so they can take the necessary actions.
I think behind the lines of updating https://calcite.apache.org/news/
We might want to mention the following regressions, and we might want to
mark the release
Hey Stamatis,
Thanks for putting this together for 2020. Thank you for being our chair
for 2020 and the excellent work you have done in this capacity.
I agree that reviewing pull requests is still an issue with the project
and while we have made a lot of progress it this area, it's still
Thanks for raising awareness Vladimir.
To be honest, I am not sure how we should move forward but I think it's a
bit late to ask people not to upgrade.
We can let people know about the potential issues but I guess this is
already done via this mail.
People who are responsible for upgrading
Vladimir Sitnikov created CALCITE-4388:
--
Summary: RexNode#isAlwaysFalse and isAlwaysTrue should be aligned
with RexSimplify#isSafeExpression
Key: CALCITE-4388
URL:
Vladimir Sitnikov created CALCITE-4387:
--
Summary: Document that RexSimplify.simplifyUnknownAs could narrow
or widen nullness of the given expression
Key: CALCITE-4387
URL:
Hi,
Can anybody clarify if RelRule should be allowed to change RelNode field
nullability?
For instance, RelOptRulesTest#testReduceNullableToNotNull has the following
SQL:
...empno + *case* when 'a' = 'a' then 1 else *null end* as newcol...
Of course, the initial type is nullable int (since the
xzh_dz created CALCITE-4386:
---
Summary: Support RelShuttle visit specific logical operators
Key: CALCITE-4386
URL: https://issues.apache.org/jira/browse/CALCITE-4386
Project: Calcite
Issue Type:
Jiatao Tao created CALCITE-4385:
---
Summary: Adding optimization to simplify the And/Or condition
Key: CALCITE-4385
URL: https://issues.apache.org/jira/browse/CALCITE-4385
Project: Calcite
xzh_dz created CALCITE-4384:
---
Summary: Predicate can not satisfy the condition of materialized
recognition
Key: CALCITE-4384
URL: https://issues.apache.org/jira/browse/CALCITE-4384
Project: Calcite
15 matches
Mail list logo
