[jira] [Created] (CALCITE-4563) Allow auxiliary SqlGroupedWindowFunction to specify returnTypeInference
Leonard Xu created CALCITE-4563: --- Summary: Allow auxiliary SqlGroupedWindowFunction to specify returnTypeInference Key: CALCITE-4563 URL: https://issues.apache.org/jira/browse/CALCITE-4563 Project: Calcite Issue Type: Improvement Reporter: Leonard Xu in CALCITE-2133 we allowed SqlGroupedWindowFunction to specify returnTypeInference in its constructor, but for auxiliary SqlGroupedWindowFunction, the returnTypeInference is fixed as *ReturnTypes.ARG0*, we can also enable user to config it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4555) Invalid zero literal value is used for TIMESTAMP WITH LOCAL TIME ZONE type in RexBuilder
Leonard Xu created CALCITE-4555:
---
Summary: Invalid zero literal value is used for TIMESTAMP WITH
LOCAL TIME ZONE type in RexBuilder
Key: CALCITE-4555
URL: https://issues.apache.org/jira/browse/CALCITE-4555
Project: Calcite
Issue Type: Bug
Reporter: Leonard Xu
The zero literal value for TIMESTAMP WITH LOCAL TIME ZONE type is used in
`org.apache.calcite.rex.RexBuilder`
{code:java}
case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
return new TimestampString(0, 0, 0, 0, 0, 0);
//TimestampString(int year, int month, int day, int h, int m, int s)
{code}
the month and day should never be zero
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4554) TIMESTAMP WITH LOCAL TIME ZONE type is not supported in Snapshot and MatchRecognize validation
Leonard Xu created CALCITE-4554: --- Summary: TIMESTAMP WITH LOCAL TIME ZONE type is not supported in Snapshot and MatchRecognize validation Key: CALCITE-4554 URL: https://issues.apache.org/jira/browse/CALCITE-4554 Project: Calcite Issue Type: Improvement Reporter: Leonard Xu When I plan to support `TIMESTAMP WITH LOCAL TIME ZONE` type in Flink project , I found only `TIMESTAMP` is supported in system period type of `Snapshot` node and first orderBy column type of `MatchRecognize` node in Calcite. So I have to override the class `org.apache.calcite.sql.validate.SqlValidatorImpl` to skip the validate logic. Both `TIMESTAMP` and `TIMESTAMP WITH LOCAL TIME ZONE` belong to `SqlTypeFamily.TIMESTAMP`, Could we also support `TIMESTAMP WITH LOCAL TIME ZONE` in these situation? -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [ANNOUNCE] New committer: Vineet Garg
Congratulations, Vineet! Best, Leonard Xu > 在 2020年4月26日，18:07，xu 写道： > > Congrats, Vineet! > > Danny Chan 于2020年4月26日周日 下午4:52写道： > >> Congrats, Vineet! >> >> Best, >> Danny Chan >> 在 2020年4月26日 +0800 PM1:55，dev@calcite.apache.org，写道： >>> >>> Congrats, Vineet! >> > > > -- > > Best regards, > > Xu
Re: [ANNOUNCE] Haisheng Yuan joins Calcite PMC
Congratulations! HaiSheng Best, Leonard Xu > On 2019年11月11日, at 下午1:22, Danny Chan wrote: > > Congratulations HaiSheng!
Re: [ANNOUNCE] Danny Chan joins Calcite PMC
Congratulation！ Danny > On 2019年10月31日, at 上午9:06, Andrei Sereda wrote: > > Congrats, Danny! > > On Wed, Oct 30, 2019 at 8:08 PM Julian Hyde wrote: > >> Congratulations, Danny! Thank you for all of your hard work on code, >> reviewing others' work, answering questions, and generally making our >> community welcoming to all! >> >> Julian >> >> On Wed, Oct 30, 2019 at 4:32 PM Michael Mior wrote: >>> >>> Welcome on board Danny! Glad to have you. >>> -- >>> Michael Mior >>> mm...@apache.org >>> >>> Le mer. 30 oct. 2019 à 17:22, Francis Chuang >>> a écrit : I'm pleased to announce that Danny has accepted an invitation to join the Calcite PMC. Danny has been a consistent and helpful figure in the Calcite community for which we are very grateful. We look forward to the continued contributions and support. Please join me in congratulating Danny! - Francis (on behalf of the Calcite PMC) >>
Apply contribution permission
Hi,calcite community. I’d like to contribute to community, could you kindly give me the contribution permission. My JIRA ID is:Leonard Xu Best， Leonard
[jira] [Created] (CALCITE-3368) Nonequivalent simplification happens in RexSimplify
Leonard Xu created CALCITE-3368:
---
Summary: Nonequivalent simplification happens in RexSimplify
Key: CALCITE-3368
URL: https://issues.apache.org/jira/browse/CALCITE-3368
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.21.0
Reporter: Leonard Xu
Fix For: 1.22.0
When I do some overflow test ，I found that Calcite's simplification logic of
isNull expression will convert from
*"f(operand0, operand1) IS NULL"* to
*"operand0 IS NULL OR operand1 IS NULL"* if the Policy of RexNode‘s SqlKind
is ANY 。
This simplification will not calculate the real vale of *f(operand0,
operand1)* (eg..'f0 + 'f1 ）which maybe overflow.
{code:java}
//org.apache.calcite.rex.RexSimplify.java
private RexNode simplifyIsNull(RexNode a) {
// Simplify the argument first,
// call ourselves recursively to see whether we can make more progress.
// For example, given
// "(CASE WHEN FALSE THEN 1 ELSE 2) IS NULL" we first simplify the
// argument to "2", and only then we can simplify "2 IS NULL" to "FALSE".
a = simplify(a, UNKNOWN);
if (!a.getType().isNullable() && isSafeExpression(a)) {
return rexBuilder.makeLiteral(false);
}
if (RexUtil.isNull(a)) {
return rexBuilder.makeLiteral(true);
}
if (a.getKind() == SqlKind.CAST) {
return null;
}
switch (Strong.policy(a.getKind())) {
case NOT_NULL:
return rexBuilder.makeLiteral(false);
case ANY:
// "f" is a strong operator, so "f(operand0, operand1) IS NULL" simplifies
// to "operand0 IS NULL OR operand1 IS NULL"
final List operands = new ArrayList<>();
for (RexNode operand : ((RexCall) a).getOperands()) {
final RexNode simplified = simplifyIsNull(operand);
if (simplified == null) {
operands.add(
rexBuilder.makeCall(SqlStdOperatorTable.IS_NULL, operand));
} else {
operands.add(simplified);
}
}
return RexUtil.composeDisjunction(rexBuilder, operands, false);
case AS_IS:
default:
return null;
}
}{code}
And most of calculating SqlKinds are assigned *Policy.ANY* at present.
{code:java}
//org.apache.calcite.plan.Strong.java
public static Policy policy(SqlKind kind) {
return MAP.getOrDefault(kind, Policy.AS_IS);
}
map.put(SqlKind.PLUS, Policy.ANY);
map.put(SqlKind.PLUS_PREFIX, Policy.ANY);
map.put(SqlKind.MINUS, Policy.ANY);
map.put(SqlKind.MINUS_PREFIX, Policy.ANY);
map.put(SqlKind.TIMES, Policy.ANY);
map.put(SqlKind.DIVIDE, Policy.ANY);
* that operator evaluates to null. */
public enum Policy {
/** This kind of expression is never null. No need to look at its arguments,
* if it has any. */
NOT_NULL,
/** This kind of expression has its own particular rules about whether it
* is null. */
CUSTOM,
/** This kind of expression is null if and only if at least one of its
* arguments is null. */
ANY,
/** This kind of expression may be null. There is no way to rewrite. */
AS_IS,
}{code}
It should be an obvious nonequivalent simplification.
And this issue come from Flink
（[FLINK-14030|https://issues.apache.org/jira/browse/FLINK-14030]）.
[~danny0405] could you have a look at this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
