[jira] [Created] (CALCITE-3360) SqlValidator throws NEP for unregistered function without implicit type coercion
Danny Chan created CALCITE-3360: --- Summary: SqlValidator throws NEP for unregistered function without implicit type coercion Key: CALCITE-3360 URL: https://issues.apache.org/jira/browse/CALCITE-3360 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.21.0 Reporter: Danny Chan Assignee: Danny Chan Fix For: 1.22.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3331) Support implicit type cast for single operand family checker
Danny Chan created CALCITE-3331: --- Summary: Support implicit type cast for single operand family checker Key: CALCITE-3331 URL: https://issues.apache.org/jira/browse/CALCITE-3331 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.20.0 Reporter: Danny Chan Assignee: Danny Chan Fix For: 1.22.0 When the FamilyOperandTypeChecker is used to check single operand data type, support implicit type coercion if we can. Now some of the sql operator override method #checkOperandTypes, and use the SqlSingleOperandTypeChecker#checkSingleOperandType to check the operand data type, we should support the implicit type coercion for these operators. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3311) Add doc to site for implicit type coercion
Danny Chan created CALCITE-3311: --- Summary: Add doc to site for implicit type coercion Key: CALCITE-3311 URL: https://issues.apache.org/jira/browse/CALCITE-3311 Project: Calcite Issue Type: Sub-task Components: site Affects Versions: 1.20.0 Reporter: Danny Chan Assignee: Danny Chan Fix For: 1.21.0 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3310) Approximate and exact aggregate calls are recognized as the same during sql-to-rel conversion
Danny Chan created CALCITE-3310:
---
Summary: Approximate and exact aggregate calls are recognized as
the same during sql-to-rel conversion
Key: CALCITE-3310
URL: https://issues.apache.org/jira/browse/CALCITE-3310
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.20.0
Reporter: Danny Chan
Assignee: Danny Chan
Fix For: 1.21.0
For sql:
{code:sql}
SELECT empno, count(distinct ename)
approx_count_distinct(ename)
FROM emp
GROUP BY empno
{code}
After sql-to-rel conversion, the plan is:
{code:sql}
LogicalProject(EMPNO=[$0], EXPR$1=[$1], EXPR$2=[$1])
LogicalAggregate(group=[{0}], EXPR$1=[COUNT(DISTINCT $1)])
LogicalProject(EMPNO=[$0], ENAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3271) TVF windowing and EMIT syntax support in Calcite
Danny Chan created CALCITE-3271: --- Summary: TVF windowing and EMIT syntax support in Calcite Key: CALCITE-3271 URL: https://issues.apache.org/jira/browse/CALCITE-3271 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.20.0 Reporter: Danny Chan Assignee: Danny Chan Copied from the mailing list: Calcite has not implemented the syntax in that paper. I would support an effort to add it (unsurprising, since I am a co-author of that paper). EMIT STREAM is equivalent to the current SELECT STREAM syntax. There is no equivalent in current Calcite of the EMIT AFTER WATERMARK, or EMIT STREAM AFTER DELAY. HOP, TUMBLE and SESSION are supported in Calcite’s SQL parser, but following the paper would be replaced with a table function call. We could need to add HOP, TUMBLE and SESSION table functions. We would also need to make the system aware of how watermarks flow through these table functions (an area that the paper does not go into). Julian -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3269) Returns integer for VARCHAR and INT division of PostgreSql dialect
Danny Chan created CALCITE-3269: --- Summary: Returns integer for VARCHAR and INT division of PostgreSql dialect Key: CALCITE-3269 URL: https://issues.apache.org/jira/browse/CALCITE-3269 Project: Calcite Issue Type: Sub-task Components: core Affects Versions: 1.21.0 Reporter: Danny Chan Assignee: Danny Chan We are planning to fix this for PostgreSQL, but maybe not in 1.21.0. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3250) Support nested collection type for SqlDataTypeSpec
Danny Chan created CALCITE-3250:
---
Summary: Support nested collection type for SqlDataTypeSpec
Key: CALCITE-3250
URL: https://issues.apache.org/jira/browse/CALCITE-3250
Project: Calcite
Issue Type: Sub-task
Reporter: Danny Chan
Assignee: Danny Chan
According to SQL-2011, collection type can be nested:
{code:sql}
::=
ARRAY []
::=
{code}
*Example*:
{code:sql}
int array array;
int multiset array;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3238) Support Time Zone suffix of DateTime types for SqlDataTypeSpec
Danny Chan created CALCITE-3238: --- Summary: Support Time Zone suffix of DateTime types for SqlDataTypeSpec Key: CALCITE-3238 URL: https://issues.apache.org/jira/browse/CALCITE-3238 Project: Calcite Issue Type: Sub-task Reporter: Danny Chan -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (CALCITE-3233) Support Row type for SqlDataTypeSpec
Danny Chan created CALCITE-3233:
---
Summary: Support Row type for SqlDataTypeSpec
Key: CALCITE-3233
URL: https://issues.apache.org/jira/browse/CALCITE-3233
Project: Calcite
Issue Type: Sub-task
Components: core
Affects Versions: 1.20.0
Reporter: Danny Chan
Assignee: Danny Chan
Fix For: 1.21.0
This is the grammar copied from SQL-2011:
{code:sql}
::=
ROW
::=
[ { }... ]
::=
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3232) Add syntax for type in site reference page
Danny Chan created CALCITE-3232: --- Summary: Add syntax for type in site reference page Key: CALCITE-3232 URL: https://issues.apache.org/jira/browse/CALCITE-3232 Project: Calcite Issue Type: Sub-task Reporter: Danny Chan Assignee: Danny Chan -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (CALCITE-3231) Support ARRAY type for SqlDataTypeSpec
Danny Chan created CALCITE-3231:
---
Summary: Support ARRAY type for SqlDataTypeSpec
Key: CALCITE-3231
URL: https://issues.apache.org/jira/browse/CALCITE-3231
Project: Calcite
Issue Type: Sub-task
Components: core
Affects Versions: 1.20.0
Reporter: Danny Chan
Assignee: Danny Chan
Fix For: 1.21.0
Support the grammar in parser as follows:
{code:sql}
array[int_size] -- or
array
type array
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3213) Support complex type expressions for SqlDataTypeSpec
Danny Chan created CALCITE-3213:
---
Summary: Support complex type expressions for SqlDataTypeSpec
Key: CALCITE-3213
URL: https://issues.apache.org/jira/browse/CALCITE-3213
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.20.0
Reporter: Danny Chan
Assignee: Danny Chan
Fix For: 1.21.0
We should support nested struct type like:
{code:sql}
ROW(
NUMBER(5, 2) NOT NULL AS foo,
ROW(BOOLEAN AS b, MyUDT NOT NULL AS i) AS rec)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3201) Skip validation for sql insert columns with column strategy that can not insert into
Danny Chan created CALCITE-3201:
---
Summary: Skip validation for sql insert columns with column
strategy that can not insert into
Key: CALCITE-3201
URL: https://issues.apache.org/jira/browse/CALCITE-3201
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.20.0
Reporter: Danny Chan
Assignee: Danny Chan
Fix For: 1.21.0
Now if we have a target table with schema:
{code:sql}
t1
: - a int not null
- b bigint STORED
- c varchar VIRTUAL
{code}
and validate a query like:
{code:sql}
insert into t1 select a from t1;
{code}
It would throw exception because the target table fields count is 3 but the
query is 1,
actually the table t1 columns b and c have strategy that we can not insert
into, so we better
ignore these columns when do validation
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3168) Add test for invalid literal of sql parser
Danny Chan created CALCITE-3168: --- Summary: Add test for invalid literal of sql parser Key: CALCITE-3168 URL: https://issues.apache.org/jira/browse/CALCITE-3168 Project: Calcite Issue Type: Sub-task Reporter: Danny Chan Assignee: Danny Chan -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3161) Remove deprecated SemiJoinType usage completely
Danny Chan created CALCITE-3161: --- Summary: Remove deprecated SemiJoinType usage completely Key: CALCITE-3161 URL: https://issues.apache.org/jira/browse/CALCITE-3161 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.20.0 Reporter: Danny Chan Assignee: Danny Chan Fix For: 1.21.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3152) Unify throws in sql parser
Danny Chan created CALCITE-3152:
---
Summary: Unify throws in sql parser
Key: CALCITE-3152
URL: https://issues.apache.org/jira/browse/CALCITE-3152
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.20.0
Environment: {color:#33}Copied from DEV mail,{color}
{color:#33}Now our parser has 3 kinds of throws behavior:
[1] Use JavaCC generateParseException
[2] Use SqlUtil.newContextException
[3] Use JavaCC ParseExecption directly
For [1] and [2] there is a position info in the exception message, a throw may
like:{color}
{code:java}
>From line 1, column 15 to line 1, column 26:
{code}
{color:#33}{color:#33}But for 3, we only have the error message without
position info, which is not that user friendly when the sql text is huge (there
are 10 occurance for 3 in our parser). So shall we unify them ? E.G. Use only 1
and 2 is enough for all the cases, the 2 can totally replace 3.{color}{color}
{color:#33}{color:#33}{color:#33}[1]
[https://github.com/apache/calcite/blob/69c8053cd98ec65c55fa1c3b282b076536ab758f/core/src/main/codegen/templates/Parser.jj#L4494]
[2]
[https://github.com/apache/calcite/blob/69c8053cd98ec65c55fa1c3b282b076536ab758f/core/src/main/codegen/templates/Parser.jj#L386]
[3]
[https://github.com/apache/calcite/blob/69c8053cd98ec65c55fa1c3b282b076536ab758f/core/src/main/codegen/templates/Parser.jj#L601]{color}{color}{color}
Reporter: Danny Chan
Assignee: Danny Chan
Fix For: 1.21.0
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-3148) Validator throws IndexOutOfBoundsException for SqlInsert when source and sink have non-equal fields number
Danny Chan created CALCITE-3148: --- Summary: Validator throws IndexOutOfBoundsException for SqlInsert when source and sink have non-equal fields number Key: CALCITE-3148 URL: https://issues.apache.org/jira/browse/CALCITE-3148 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.20.0 Reporter: Danny Chan Assignee: Danny Chan Fix For: 1.21.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3126) Remove deprecated SemiJoin usage completely
Danny Chan created CALCITE-3126: --- Summary: Remove deprecated SemiJoin usage completely Key: CALCITE-3126 URL: https://issues.apache.org/jira/browse/CALCITE-3126 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.19.0 Reporter: Danny Chan Assignee: Danny Chan Fix For: 1.21.0 As a following of CALCITE-2969, Julian Hyde has keep some deprecated usage of SemiJoin class while supress the warnings[1], they are expected to be removed from version 1.21 [1] [https://github.com/apache/calcite/commit/ef0c4c6ddb7553e2e858259007d8ca1cb3692101] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3083) Add demos(how to) doc for all supported DDLs and DMLs
Danny Chan created CALCITE-3083:
---
Summary: Add demos(how to) doc for all supported DDLs and DMLs
Key: CALCITE-3083
URL: https://issues.apache.org/jira/browse/CALCITE-3083
Project: Calcite
Issue Type: Bug
Components: site
Affects Versions: 1.19.0
Reporter: Danny Chan
Assignee: Danny Chan
Copied from DEV mail:
Dear Dev Team's Apache Calcite,
My name is Duc. I'm working at Toshiba Group in Vietnam.
I'm implementing how to parser DDL file using library Apache Calcite.
I'm trying with below solution, but has exception is thrown and i don't know
that why.
{code:java}
InputStream ddlFile = new FileInputStream("ddlTest.sql");
SqlDdlParserImpl ddlParser = new SqlDdlParserImpl(ddlFile,"UTF8");
SqlNode node = ddlParser.SqlStmt(); {code}
Could you please send me a example of DDL file or give me a suggestion about
this proplem.
We indeed need detail demos about our grammars, that will let users to some
fast start up and our site more user friendly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-3037) Rename EnumerableThetaJoin to EnumerableNestedLoopJoin
Danny Chan created CALCITE-3037: --- Summary: Rename EnumerableThetaJoin to EnumerableNestedLoopJoin Key: CALCITE-3037 URL: https://issues.apache.org/jira/browse/CALCITE-3037 Project: Calcite Issue Type: Improvement Components: core Reporter: Danny Chan Fix For: 1.20.0 Rename EnumerableThetaJoin and EnumerableCorrelate(already done) all to EnumerableNestedLoop, the difference is that EnumerableCorrelate will take correlate variables(required columns) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3036) Remove correlate variables from Join
Danny Chan created CALCITE-3036: --- Summary: Remove correlate variables from Join Key: CALCITE-3036 URL: https://issues.apache.org/jira/browse/CALCITE-3036 Project: Calcite Issue Type: Improvement Components: core Reporter: Danny Chan Assignee: Danny Chan Fix For: 1.20.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3016) Reorganize the operator tables
Danny Chan created CALCITE-3016: --- Summary: Reorganize the operator tables Key: CALCITE-3016 URL: https://issues.apache.org/jira/browse/CALCITE-3016 Project: Calcite Issue Type: Improvement Affects Versions: 1.19.0, 1.20.0 Reporter: Danny Chan Assignee: Danny Chan Reorganize the operator tables # Make a CommonOperatorTable for operators that belong to multiple dialect # create a dialect to operator table mapping cache for used dialect # annotation the function with specific annotation for operators in CommonOperatorTable -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2966) Problem with Code Generation
Danny Chan created CALCITE-2966: --- Summary: Problem with Code Generation Key: CALCITE-2966 URL: https://issues.apache.org/jira/browse/CALCITE-2966 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.20.0 Reporter: Danny Chan Assignee: Danny Chan Fix For: 1.20.0 >From the mailing list: Hi all, I have some problems with the code generation from Linq4j which I'm unable to resolve myself. Basically, I want to translate a condition from Rex to a Linq4j expression to use it in generated code. In my example the Condition is from Match Recognize and in SQL is: `up."commission" > prev(up."commission")`. ``` RexBuilder rexBuilder = new RexBuilder(implementor.getTypeFactory()); RexProgramBuilder rexProgramBuilder = new RexProgramBuilder(physType.getRowType(), rexBuilder); rexProgramBuilder.addCondition(entry.getValue()); final Expression condition = RexToLixTranslator.translateCondition(rexProgramBuilder.getProgram(), (JavaTypeFactory) getCluster().getTypeFactory(), builder2, inputGetter1, implementor.allCorrelateVariables, implementor.getConformance()); builder2.add(Expressions.return_(null, condition)); ``` Here, the condition seems okay, it is: ">(PREV(UP.$4, 0), PREV(UP.$4, 1))", so it should be a comparison of two variables (I rewrite the PREV with a custom Input Getter". But, the generated code (for Janino) is: ``` Object p1 = row_.get($L4J$C$0_1); org.apache.calcite.test.JdbcTest.Employee p0 = (org.apache.calcite.test.JdbcTest.Employee) p1; Object p3 = row_.get($L4J$C$1_1); org.apache.calcite.test.JdbcTest.Employee p2 = (org.apache.calcite.test.JdbcTest.Employee) p3; Object p5 = row_.get($L4J$C$0_1); org.apache.calcite.test.JdbcTest.Employee p4 = (org.apache.calcite.test.JdbcTest.Employee) p5; Object p7 = row_.get($L4J$C$1_1); org.apache.calcite.test.JdbcTest.Employee p6 = (org.apache.calcite.test.JdbcTest.Employee) p7; return p0.commission && p2.commission && p4.commission > p6.commission; ``` This confuses me a lot as I do not know where the check for p0.commission and p2.commission comes from. It seems that Linq4j adds them as it expects these variables to be nullable, but I have no idea on how to avoid this. These fields are Numeric so I always get a compilation exception. Can someone help me with this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2938) Druid adapter do wrong behavior for casts from timestamp type to date type
Danny Chan created CALCITE-2938:
---
Summary: Druid adapter do wrong behavior for casts from timestamp
type to date type
Key: CALCITE-2938
URL: https://issues.apache.org/jira/browse/CALCITE-2938
Project: Calcite
Issue Type: Improvement
Components: druid
Affects Versions: 1.19.0
Reporter: Danny Chan
Assignee: Danny Chan
Fix For: 1.20.0
For sql like
{code:java}
Select cast("timestamp" as date) as t from "foodmart" order by t limit 1
{code}
It produces results:
3242-06-03
while it expects to be:
1997-01-01
You can past the code
{code:java}
@Test
public void testCastTimestamp() {
final String sql = "Select cast(\"timestamp\" as date) as t"
+ " from \"foodmart\" order by t limit 1";
sql(sql, FOODMART)
.returnsOrdered("T=1997-01-01 00:00:00")
.queryContains(
druidChecker("UTC"));
}
{code}
in DruidAdapterIT2 and reproduce it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2928) Make UDF lookup default to case insensitive
Danny Chan created CALCITE-2928:
---
Summary: Make UDF lookup default to case insensitive
Key: CALCITE-2928
URL: https://issues.apache.org/jira/browse/CALCITE-2928
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.19.0
Reporter: Danny Chan
Assignee: Danny Chan
Fix For: 1.19.0
Now for Calcite, we make default parser config unquotedCasing to
Lex.ORACLE.unquotedCasing(to uppercase)[1], and caseSensitive to
Lex.ORACLE.caseSensitive(case sensitive true).
So if we have a UDAF named my_func and query with sql like:
{code:java}
select f0, my_func(f1) from table1 group by f0;
{code}
We would got a unparsed sql:
{code:java}
SELECT F0, MY_FUNC(F1) FROM TABLE1 GROUP BY F0;
{code}
For CalciteCatalogReader we hard code the function look up to case sensitive
true[2],
For ListSqlOperatorTable we make the operator name lookup case sensitive
true[3].
For ReflectiveSqlOperatorTable, we make built-in operators
case-insensitively[4].
For most of the cases, we use ListSqlOperatorTable to register our UDFs[5]
chained with SqlStdOperatorTable(which composite a ChainedSqlOperatorTable),
which finally passed to CalciteCatalogReader for validation.
So there are some questions i have:
1. Why we make built-in operators look up case-insensitively while
ListSqlOperatorTable(for UDFs) case-sensitively, with default unquotedCasing of
TO_UPPERCASE.
2. What is the usage of CalciteCatalogReader#lookupOperatorOverloads i only saw
it used in a unit test LookupOperatorOverloadsTest.
It seems that make UDF look up case-sensitively does not make any sense, users
will never distinguish their function with just word cases. And i checked also
MYSQL, ORACLE, POSTGRES, their UDFs are all registered case-insensitively.
[1]
https://github.com/apache/calcite/blob/ffca956be03a99cd11e440d652b09674aaa727e6/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java#L231
[2]
https://github.com/apache/calcite/blob/ffca956be03a99cd11e440d652b09674aaa727e6/core/src/main/java/org/apache/calcite/prepare/CalciteCatalogReader.java#L166
[3]
https://github.com/apache/calcite/blob/ffca956be03a99cd11e440d652b09674aaa727e6/core/src/main/java/org/apache/calcite/sql/util/ListSqlOperatorTable.java#L63
[4]
https://github.com/apache/calcite/blob/ffca956be03a99cd11e440d652b09674aaa727e6/core/src/main/java/org/apache/calcite/sql/util/ReflectiveSqlOperatorTable.java#L103
[5]
https://github.com/apache/calcite/blob/ffca956be03a99cd11e440d652b09674aaa727e6/core/src/test/java/org/apache/calcite/test/MockSqlOperatorTable.java#L46
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
