xiedeyantu commented on code in PR #4247:
URL: https://github.com/apache/calcite/pull/4247#discussion_r2014225423
##########
core/src/main/java/org/apache/calcite/sql/dialect/ClickHouseSqlDialect.java:
##########
@@ -181,6 +188,21 @@ private static SqlDataTypeSpec
createSqlDataTypeSpecByName(String typeAlias,
return;
}
+ if (call.getOperator() instanceof SqlFilterOperator) {
+ SqlCall aggCall = call.operand(0);
+ if (call.getOperandList().size() > 1 && call.operand(1) != null) {
+ SqlCall filterCondition = call.operand(1);
+ String functionName = aggCall.getOperator().getName();
+ writer.print(functionName.toLowerCase(Locale.ROOT) + "If");
Review Comment:
> Whether clickhouse supports stddev is what I am asking. Calcite supports a
set of aggregates, and clickhouse supports another set. If the Calcite set is
included in the Clickhouse set, this change is fine.
@mihaibudiu After seeing your and cancai's replies, maybe I didn't explain
clearly enough. Let me elaborate on the issue I mentioned:
ClickHouse doesn't support stddev. Converting stddev(x) filter(where) to
stddevIf(x, condition) will throw an error in ClickHouse. What I meant in my
previous reply was that using stddev(case when) would also throw an error. This
PR is just making a formal transformation.
If we want to properly solve whether aggregate functions or other functions
can be correctly translated, maybe creating a new JIRA ticket would be better.
What do you think?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
