[jira] [Created] (CALCITE-5275) Release Calcite 1.32.0

2022-09-07 Thread Julian Hyde (Jira) 
Julian Hyde created CALCITE-5275:


 Summary: Release Calcite 1.32.0
 Key: CALCITE-5275
 URL: https://issues.apache.org/jira/browse/CALCITE-5275
 Project: Calcite
  Issue Type: Bug
Reporter: Julian Hyde
 Fix For: 1.32.0


Release Calcite 1.32.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Jenkins build is back to normal : Calcite » Calcite-snapshots #217

2022-09-07 Thread Apache Jenkins Server 
See

[jira] [Created] (CALCITE-5274) prevent XXE possibilities in DiffRepository (calcite testkit)

2022-09-07 Thread PJ Fanning (Jira) 
PJ Fanning created CALCITE-5274:
---

 Summary: prevent XXE possibilities in DiffRepository (calcite 
testkit)
 Key: CALCITE-5274
 URL: https://issues.apache.org/jira/browse/CALCITE-5274
 Project: Calcite
  Issue Type: Improvement
  Components: extensions
Reporter: PJ Fanning


[https://github.com/apache/calcite/pull/2892#discussion_r964468020]

DocumentBuilderFactory use in DiffRepository needs changes like those in 
[https://github.com/apache/calcite/pull/2892|https://github.com/apache/calcite/pull/2892#discussion_r964468020]

There is also an issue with `this.doc = 
docBuilder.parse(refFile.openStream());` - the `refFile.openStream()` gives an 
InputStream that should be closed - try with resources pattern would make sense.

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Firebolt dialect

2022-09-07 Thread Aymeric Dispa 
Hi,

I am a software engineer at Firebolt and I need to make a few changes in
the Firebolt dialect. Could someone have a look at my PR
https://issues.apache.org/jira/browse/CALCITE-5217 /
https://github.com/apache/calcite/pull/2860 ?

Thanks !

Build failed in Jenkins: Calcite » Calcite-snapshots #216

2022-09-07 Thread Apache Jenkins Server 
See 


Changes:

[Julian Hyde] Add tests for correlated CTEs


--
[...truncated 352.19 KB...]
 42.3sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery13()
 42.3sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery14()
 42.3sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery06()
 42.6sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery01()
 20.1sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery20()

> Task :geode:test
 11.0sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlMultipleTimestampWhereFilter()
 11.1sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlSingleBooleanWhereFilter()
 10.8sec, 
org.apache.calcite.adapter.geode.rel.GeodeBookstoreTest > 
testInSetFilterWithNestedStringField()
 10.8sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlMultipleTimeWhereFilter()
 10.8sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlMultipleDateWhereFilter()
 11.0sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlMultipleBooleanWhereFilter()
 10.8sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlBooleanColumnFilter()
 11.1sec, 
org.apache.calcite.adapter.geode.rel.GeodeBookstoreTest > 
testSqlSimple()
 11.2sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlBooleanColumnNotFilter()
 11.0sec, 
org.apache.calcite.adapter.geode.rel.GeodeZipsTest > 
testSelectLocItem()
 11.0sec, 
org.apache.calcite.adapter.geode.rel.GeodeZipsTest > 
testSqlSingleStringWhereFilter()
 11.2sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlWhereWithMultipleOrForLiteralFields()
 11.6sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlWhereWithMultipleOrForAllFields()
 11.2sec, 
org.apache.calcite.adapter.geode.rel.GeodeZipsTest > 
testMaxRaw()
 11.2sec, 
org.apache.calcite.adapter.geode.rel.GeodeBookstoreTest > 
testAddMissingGroupByColumnToProjectedFields()
 11.4sec, 
org.apache.calcite.adapter.geode.rel.GeodeZipsTest > 
testWhereWithOrForNestedNumericField()
 11.5sec, 
org.apache.calcite.adapter.geode.rel.GeodeZipsTest > 
testWhereWithOrForNumericField()
 11.5sec, 
org.apache.calcite.adapter.geode.rel.GeodeZipsTest > 
testGroupByRawWithAliases()
 11.7sec, 
org.apache.calcite.adapter.geode.rel.GeodeBookstoreTest > 
testFilterWithNestedField()
 12.4sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlSingleTimestampWhereFilter()
 13.0sec, 
org.apache.calcite.adapter.geode.rel.GeodeZipsTest > 
testWhereWithOrForLargeValueList()
 13.0sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlSingleDateWhereFilter()
 13.0sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlSingleTimeWhereFilter()
 30.2sec,   12 completed,   0 failed,   0 skipped, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest
  2.5sec, 
org.apache.calcite.adapter.geode.rel.GeodeBookstoreTest > 
testWhereWithOr()
  2.1sec, 
org.apache.calcite.adapter.geode.rel.GeodeBookstoreTest > 
testMaxMinSumAvg()
  2.1sec, 
org.apache.calcite.adapter.geode.rel.GeodeBookstoreTest > 
testMaxMinSumAvgInGroupBy()
 14.0sec, 
org.apache.calcite.adapter.geode.rel.GeodeZipsTest > 
testItemPredicate()
WARNING  31.1sec,   14 completed,   0 failed,   3 
skipped, org.apache.calcite.adapter.geode.rel.GeodeZipsTest
  2.3sec, 
org.apache.calcite.adapter.geode.rel.GeodeBookstoreTest > 
testWhereWithOrAnd()
 31.8sec,   36 completed,   0 failed,   0 skipped,

[jira] [Created] (CALCITE-5273) RelToSqlConverter allows unparsing of invalid CASE expression

2022-09-07 Thread Ian Bertolacci (Jira) 
Ian Bertolacci created CALCITE-5273:
---

 Summary: RelToSqlConverter allows unparsing of invalid CASE 
expression
 Key: CALCITE-5273
 URL: https://issues.apache.org/jira/browse/CALCITE-5273
 Project: Calcite
  Issue Type: Bug
Reporter: Ian Bertolacci


RelToSqlConverter will unparse the invalid† CASE expression {{`CASE ELSE 1 
END`}} (which can be constructed using either RelBuilder or RexBuilder, see 
CALCITE-5272).
(† Or at least and expression which Calcite then cannot parse.)

Given this RelNode tree with invalid case statements
{code}
1:LogicalProject($f0=[CASE(1)], $f1=[CASE(1:BIGINT)])
  0:LogicalValues(tuples=[[{ 0 }]])
{code}

Unparsing with RelToSqlConverter using MysqlSqlDialect.DEFAULT‡ gives the Sql:
{code}
SELECT CASE ELSE 1 END AS `$f0`, CASE ELSE 1 END AS `$f1`
{code}

Running that sql back through the parser using Lex.MYSQL‡ and 
SqlConformanceEnum.MYSQL_5‡ throws the exception:
{code}
Incorrect syntax near the keyword 'CASE' at line 1, column 8.
Was expecting one of:
"ALL" ...
"CURSOR" ...
"DISTINCT" ...
...
org.apache.calcite.sql.parser.SqlParseException: Incorrect syntax near the 
keyword 'CASE' at line 1, column 8.
Was expecting one of:
"ALL" ...
"CURSOR" ...
"DISTINCT" ...
...
at 
org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:389)
at 
org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:153)
at 
org.apache.calcite.sql.parser.SqlParser.handleException(SqlParser.java:145)
at 
org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:160)
at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:185)
at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:214)
at org.apache.calcite.tools.Planner.parse(Planner.java:50)
..
Caused by: org.apache.calcite.sql.parser.impl.ParseException: Incorrect syntax 
near the keyword 'CASE' at line 1, column 8.
Was expecting one of:
"ALL" ...
"CURSOR" ...
"DISTINCT" ...
...
at 
org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:349)
... 59 more
{code}

‡ I don't believe the specific dialect/lex/conformance parameters affect the 
outcome.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CALCITE-5272) RelBuilder/RexBuilder allow creation of invalid CASE expression

2022-09-07 Thread Ian Bertolacci (Jira) 
Ian Bertolacci created CALCITE-5272:
---

 Summary: RelBuilder/RexBuilder allow creation of invalid CASE 
expression
 Key: CALCITE-5272
 URL: https://issues.apache.org/jira/browse/CALCITE-5272
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.30.0
Reporter: Ian Bertolacci


It is possible (and easy) to create the invalid CASE expression† {{`CASE ELSE 1 
END`}} using either RelBuilder or RexBuilder.
(† Or at least and expression which Calcite then cannot parse.)

{code:scala}
val relBuilder: RelBuilder = ...
val rexBuilder: RexBuilder = ...
val typeFactory = relBuilder.getTypeFactory
// Invalid case expression that can be built
val caseExprRel = relBuilder.call(SqlStdOperatorTable.CASE, 
relBuilder.literal(1))
val caseExprRex = rexBuilder.makeCall(SqlStdOperatorTable.CASE, rexBuilder.
makeBigintLiteral(BigDecimal.valueOf(1)))
// RelNode tree with project containing invalid case expressions
val node =
  relBuilder.values(
java.util.Arrays.asList( java.util.Arrays.asList(relBuilder.literal(0)) ),
typeFactory.builder().add("x", 
typeFactory.createSqlType(SqlTypeName.INTEGER)).build()
  )
  .project(caseExprRel, caseExprRex)
  .build()
{code}

Gives the RelNode tree:
{code}
1:LogicalProject($f0=[CASE(1)], $f1=[CASE(1:BIGINT)])
  0:LogicalValues(tuples=[[{ 0 }]])
{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Error while unparsing FLOOR function using Postgres dialect

2022-09-07 Thread Parag Jain 
Hey, I have raised a ticket here -
https://issues.apache.org/jira/browse/CALCITE-5271 and it has a link to PR
as well that reproduces this issue. Took some time to figure out the test
case hence the reply got delayed. Thanks

On Thu, Sep 1, 2022 at 10:24 PM Julian Hyde  wrote:

> Parag, I think you’ve found a bug. Please follow the usual process: Log a
> jira case. Provide a PR with a test case, or, better, a PR with a test case
> and a fix.
>
>
> > On Sep 1, 2022, at 8:41 AM, Parag Jain  wrote:
> >
> > I think the biggest difference is I am calling toSql on SqlNode whereas
> the
> > test case calls toSql on RelNode here
> > <
> https://github.com/apache/calcite/blob/main/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L6724
> >
> > - SqlCall
> > for the FLOOR function in the RelNode contains YEAR as SqlLiteral in
> > operandList so it passes. This means its failing in unparsing the parsed
> > SqlCall which contains "YEAR" as SqlIntervalQualifier. Let me know if you
> > need more information. Thanks
> >
> > On Thu, Sep 1, 2022 at 8:57 PM Benchao Li  wrote:
> >
> >> Hi Parag,
> >>
> >> I added this test to `RelToSqlConverterTest`:
> >> ```java
> >> @Test void testTest() {
> >>  final String sql = "select FLOOR(TIMESTAMP '2022-08-01' TO Year)";
> >>  final String expected = "SELECT DATE_TRUNC('YEAR', TIMESTAMP
> '2022-08-01
> >> 00:00:00')\nFROM " +
> >>  "(VALUES (0)) AS \"t\" (\"ZERO\")";
> >>  sql(sql)
> >>  .withPostgresql()
> >>  .ok(expected);
> >> }
> >> ```
> >> And it passed both on the latest main branch and 1.30.0 tag.
> >>
> >> I don't know what I'm missing, could you give us an example which could
> >> reproduce this?
> >>
> >>
> >> Parag Jain  于2022年9月1日周四 19:34写道：
> >>
> >>> Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP
> >>> '2022-08-01' TO Year)
> >>>
> >>> Parsing is successful but while doing
> >>> `toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed
> >> SqlNode
> >>> I am getting following exception -
> >>>
> >>> Request failed: java.lang.ClassCastException: class
> >>> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class
> >>> org.apache.calcite.sql.SqlLiteral
> >>> at
> >>>
> >>>
> >>
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
> >>> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
> >>> at
> >>>
> >>>
> >>
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
> >>> at
> >>>
> >>>
> >>
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
> >>> at
> >>>
> >>>
> >>
> org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
> >>> at
> >>>
> >>>
> >>
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
> >>> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
> >>> at
> >>>
> >>>
> >>
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
> >>> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
> >>> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
> >>> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
> >>> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187)
> >>>
> >>> Looks like a bug as the "Year" token gets parsed to
> SqlIntervalQualifier
> >>> but expectation is of SqlLiteral ?
> >>>
> >>
> >>
> >> --
> >>
> >> Best,
> >> Benchao Li
> >>
>
>

[jira] [Created] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-07 Thread Parag Jain (Jira) 
Parag Jain created CALCITE-5271:
---

 Summary: Error while unparsing FLOOR function using Postgres 
dialect
 Key: CALCITE-5271
 URL: https://issues.apache.org/jira/browse/CALCITE-5271
 Project: Calcite
  Issue Type: Bug
Reporter: Parag Jain


Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP '2022-08-01' 
TO Year)

Parsing is successful but while doing 
`toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
getting following exception -
 
{code:java}
Request failed: java.lang.ClassCastException: class 
org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
org.apache.calcite.sql.SqlLiteral 
at 
org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
at 
org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
at 
org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
at org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
at org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
at 
org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}

Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
expectation is of SqlLiteral. Here's a 
[PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)