[jira] [Commented] (CALCITE-5570) Support nested map type for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765897#comment-17765897
]
Jiajun Xie commented on CALCITE-5570:
-
[~Sergey Nuyanzin] , Do you have any suggestions? I plan to merge it next week.
https://github.com/apache/calcite/pull/3105/files#diff-766dbf236baaf33399a8d3620404b261faa80c27dadb95379e0747f915380e44
> Support nested map type for SqlDataTypeSpec
> ---
>
> Key: CALCITE-5570
> URL: https://issues.apache.org/jira/browse/CALCITE-5570
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There was added a similar support for arrays/multisets at
> https://issues.apache.org/jira/browse/CALCITE-3250
> however there is no support for maps so far.
> The issue is to add such support.
>
> I think I'd like to clarify is syntax for maps since it has 2 internal
> subtypes for keys and values may be something similar to ROW with delimiter
> like
> {code:sql}
> SELECT CAST(NULL AS MAP(INT, INT));
> -- or with square brackets similar to map constructor
> SELECT CAST(NULL AS MAP[INT, INT]);
> -- or with angle (Flink syntax)
> SELECT CAST(NULL AS MAP);
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6007) Sqlwith as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765889#comment-17765889
]
Wenrui Meng commented on CALCITE-6007:
--
It's from sqlNode.unparse.
SqlWith means the SqlWith node statement.
{code:java}
With name as (...) select * from name
{code}
> Sqlwith as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-4189) Simplify 'p OR (p IS NOT TRUE)' to 'TRUE'
[
https://issues.apache.org/jira/browse/CALCITE-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763447#comment-17763447
]
Julian Hyde edited comment on CALCITE-4189 at 9/15/23 8:29 PM:
---
I open [PR #3416|https://github.com/apache/calcite/pull/3416].
When running the unit tests, I found that this change caused a failure in the
Geode adapter test. So, I have added a new feature to convert 'p IS NOT NULL'
to 'p <> null' in the GeodeFilter.
was (Author: JIRAUSER300840):
I open a PR([#3416|[https://github.com/apache/calcite/pull/3416])].
When running the unit tests, I found that this change caused a failure in the
Geode adapter test. So, I have added a new feature to convert 'p IS NOT NULL'
to 'p <> null' in the GeodeFilter.
> Simplify 'p OR (p IS NOT TRUE)' to 'TRUE'
> -
>
> Key: CALCITE-4189
> URL: https://issues.apache.org/jira/browse/CALCITE-4189
> Project: Calcite
> Issue Type: Improvement
>Reporter: Thomas Rebele
>Priority: Minor
> Labels: pull-request-available
>
> Statements of the form 'P OR P IS NOT TRUE' to 'TRUE' should always be true
> (please correct me if I am wrong):
> {code:java}
> > select x, X='A' as EQ,
> X='A' IS NOT TRUE as EQ_NOT_TRUE,
> (X='A') OR ((X='A') IS NOT TRUE) as EQ_OR_EQ_NOT_TRUE
> from (values 'A', 'B', null) as t(x);
> +---+---+-+---+
> | X | EQ | EQ_NOT_TRUE | EQ_OR_EQ_NOT_TRUE |
> +---+---+-+---+
> | A | true | false | true |
> | B | false | true| true |
> | | | true| true |
> +---+---+-+---+
> {code}
> Here a test case for the expected behavior:
> {code:java}
> @Test void testSimplifyPOrPNotTrue() {
> checkSimplify(
> and(
> vBool(),
> or(
> eq(vInt(), literal(1)),
> isNotTrue(eq(vInt(), literal(1)))
> )),
> "?0.bool0");
> }{code}
> There are some other, similar expressions, such as 'P IS NOT FALSE OR NOT P',
> which can be reduced to true. Maybe there's a way to handle all of them?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6000) There should be a SqlParserFixture which parses again after unparsing
[ https://issues.apache.org/jira/browse/CALCITE-6000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765845#comment-17765845 ] Mihai Budiu commented on CALCITE-6000: -- The convert bug is fixed as part of [CALCITE-5996] and the corresponding PR. > There should be a SqlParserFixture which parses again after unparsing > - > > Key: CALCITE-6000 > URL: https://issues.apache.org/jira/browse/CALCITE-6000 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Priority: Minor > > SqlParserTests parse and unparse queries. > But the unparsed result is not validated. > A new fixture should parse the final result again to validate that it's legal > SQL. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6000) There should be a SqlParserFixture which parses again after unparsing
[
https://issues.apache.org/jira/browse/CALCITE-6000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765841#comment-17765841
]
Julian Hyde commented on CALCITE-6000:
--
There's a real bug here - that "convert('abc' using utf8)" is unparsed
incorrectly.
It should be fixed. It just happens to be difficult to automate. We would not
want UnparsingTesterImpl to do validation. So the test case should be manual:
'assertThat(unparse(sql), is("something"))'.
> There should be a SqlParserFixture which parses again after unparsing
> -
>
> Key: CALCITE-6000
> URL: https://issues.apache.org/jira/browse/CALCITE-6000
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> SqlParserTests parse and unparse queries.
> But the unparsed result is not validated.
> A new fixture should parse the final result again to validate that it's legal
> SQL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5938) Update HSQLDB to Version 2.7.2
[ https://issues.apache.org/jira/browse/CALCITE-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tanner Clary resolved CALCITE-5938. --- Resolution: Fixed Merged via [f136c13|https://github.com/apache/calcite/commit/f136c13b2f165595965caa011fd22ecb6bf03f22], thanks for the review. [~julianhyde] and for opening the issue, [~shalaniw]! > Update HSQLDB to Version 2.7.2 > -- > > Key: CALCITE-5938 > URL: https://issues.apache.org/jira/browse/CALCITE-5938 > Project: Calcite > Issue Type: Bug >Reporter: Shalani Weerasooriya >Assignee: Tanner Clary >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > Upgrade HSQLDB to 2.7.1 to address CVE-2022-41853: > [https://nvd.nist.gov/vuln/detail/CVE-2022-41853]. > Calcite currently uses HSQLDB version 2.5.2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-5938) Update HSQLDB to Version 2.7.2
[ https://issues.apache.org/jira/browse/CALCITE-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tanner Clary reassigned CALCITE-5938: - Assignee: Tanner Clary > Update HSQLDB to Version 2.7.2 > -- > > Key: CALCITE-5938 > URL: https://issues.apache.org/jira/browse/CALCITE-5938 > Project: Calcite > Issue Type: Bug >Reporter: Shalani Weerasooriya >Assignee: Tanner Clary >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > Upgrade HSQLDB to 2.7.1 to address CVE-2022-41853: > [https://nvd.nist.gov/vuln/detail/CVE-2022-41853]. > Calcite currently uses HSQLDB version 2.5.2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6001) Add useUtf8AsDefaultCharset flag to SqlConformanceEnum to allow encoding of non-ISO-8859-1 characters
[
https://issues.apache.org/jira/browse/CALCITE-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765838#comment-17765838
]
Tanner Clary commented on CALCITE-6001:
---
Yeah these are all good questions/suggestions. The initial draft PR is
definitely a WIP. I'll do some more investigating next week and will get back
to you.
> Add useUtf8AsDefaultCharset flag to SqlConformanceEnum to allow encoding of
> non-ISO-8859-1 characters
> -
>
> Key: CALCITE-6001
> URL: https://issues.apache.org/jira/browse/CALCITE-6001
> Project: Calcite
> Issue Type: New Feature
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> Many dialects supported by Calcite encode their strings using a default
> charset (most commonly UTF-8 or ISO-8859-1). For example, BigQuery uses
> [UTF-8|https://cloud.google.com/bigquery/docs/reference/standard-sql/data-types#string_type].
> I am proposing to add a dialect property to be referenced when converting
> string literals so that the current dialect's default is used unless
> otherwise specified.
> Presently, if no charset is specified when converting to RexLiterals
> [here|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/rex/RexBuilder.java#L1618],
> the CalciteSystemProperty {{DEFAULT_CHARSET}} is used
> ([docs|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/config/CalciteSystemProperty.java#L300])
> which is set as ISO-8859-1.
> This means that when converting a query like:
> {{select 'ק' as result;}}
> you will get the following the error: {{Failed to encode 'ק' in character
> set 'ISO-8859-1'}}.
> This failure is unexpected if you are using BigQuery conformance(or any
> dialect whose default is UTF-8).
> Of course an alternative solution would be to just change the Calcite default
> to UTF-8 which supports encoding any UNICODE character while ISO-8859-1 can
> only encode the first 256, but I imagine there are reasons against this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5995) add cache to dejsonize function in JsonFunctions
[
https://issues.apache.org/jira/browse/CALCITE-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765837#comment-17765837
]
Julian Hyde commented on CALCITE-5995:
--
You are using a global (static) cache. Can you make the cache belong to a
function instance? That was the pattern I followed in CALCITE-5914, because I
am worried about cache persisting beyond a query's lifetime.
> add cache to dejsonize function in JsonFunctions
>
>
> Key: CALCITE-5995
> URL: https://issues.apache.org/jira/browse/CALCITE-5995
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: xiaogang zhou
>Priority: Minor
> Fix For: 1.36.0
>
>
> I used the json_value function to parse json values. And I found calcite's
> json_value function does not cache the dejsonized objects, which could cause
> some performance issue in situation below as the dejsonize function being
> called repeatedly unnecessarily.
>
> {code:java}
> select
> json_value(A, 'xxx'),
> json_value(A, 'yyy'),
> json_value(A, 'zzz'),...
> from some_table;
> {code}
>
>
> As project like flink uses the json_value to codegen it's own json_value
> function, I think this could cause a bad performance for users. So I suggest
> to introduce a cache in
>
> org.apache.calcite.runtime.JsonFunctions#dejsonize
>
> and the solution is very common in projects like hive
> [https://github.com/apache/hive/blob/storage-branch-2.3/ql/src/java/org/apache/hadoop/hive/ql/udf/generic/GenericUDTFJSONTuple.java]
>
> and of course, this feature can be turned on only some certain config is
> setted. And if this is acceptable, I think I can take the ticket. thx
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-4335) Aggregate functions for BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765835#comment-17765835
]
Julian Hyde commented on CALCITE-4335:
--
[~jiabao.sun], Thanks for raising this. Having read the BQ and Postgres doc I
agree; the return type should not be "NOT NULL". Please log a bug and submit a
PR. Please also test that Calcite returns the right result (add a query to
{{agg.iq}}). Does this issue also apply to {{ARRAY_CONCAT_AGG}},
{{STRING_AGG}}, {{LISTAGG}}, {{GROUP_CONCAT}}?
> Aggregate functions for BigQuery
>
>
> Key: CALCITE-4335
> URL: https://issues.apache.org/jira/browse/CALCITE-4335
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.27.0
>
>
> Add aggregate functions for BigQuery
> ([spec|https://cloud.google.com/bigquery/docs/reference/standard-sql/aggregate_functions]):
> {{ARRAY_AGG}}, {{ARRAY_CONCAT_AGG}}, {{COUNTIF}}, {{LOGICAL_AND}},
> {{LOGICAL_OR}}, {{STRING_AGG}}.
> Calcite already has {{ANY_VALUE}}, {{BIT_AND}}, {{BIT_OR}}, {{BIT_XOR}},
> {{MAX}}, {{MIN}}, {{SUM}} aggregate functions.
> (Edit, 2020/10/15: And, since CALCITE-2935 is fixed, it now has
> {{LOGICAL_AND}}, {{LOGICAL_OR}}.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6001) Add useUtf8AsDefaultCharset flag to SqlConformanceEnum to allow encoding of non-ISO-8859-1 characters
[
https://issues.apache.org/jira/browse/CALCITE-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765832#comment-17765832
]
Julian Hyde commented on CALCITE-6001:
--
Can we generalize, changing {{boolean useUtf8AsDefaultCharset}} to {{String
charset}}?
Charset currently allows nulls, but can we make it mandatory?
This property might be a better fit in {{SqlParser.Config}} (and possibly also
{{Lex}}) rather than {{SqlConformance}}.
There are scenarios where a DBMS would have one charset but a particular
database instance uses a different one. (MySQL does this a lot.) Your proposal
seems to support that, which is good.
Why did you remove the call to {{SqlTypeUtil.areCharacterSetsMismatched}}?
> Add useUtf8AsDefaultCharset flag to SqlConformanceEnum to allow encoding of
> non-ISO-8859-1 characters
> -
>
> Key: CALCITE-6001
> URL: https://issues.apache.org/jira/browse/CALCITE-6001
> Project: Calcite
> Issue Type: New Feature
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> Many dialects supported by Calcite encode their strings using a default
> charset (most commonly UTF-8 or ISO-8859-1). For example, BigQuery uses
> [UTF-8|https://cloud.google.com/bigquery/docs/reference/standard-sql/data-types#string_type].
> I am proposing to add a dialect property to be referenced when converting
> string literals so that the current dialect's default is used unless
> otherwise specified.
> Presently, if no charset is specified when converting to RexLiterals
> [here|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/rex/RexBuilder.java#L1618],
> the CalciteSystemProperty {{DEFAULT_CHARSET}} is used
> ([docs|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/config/CalciteSystemProperty.java#L300])
> which is set as ISO-8859-1.
> This means that when converting a query like:
> {{select 'ק' as result;}}
> you will get the following the error: {{Failed to encode 'ק' in character
> set 'ISO-8859-1'}}.
> This failure is unexpected if you are using BigQuery conformance(or any
> dialect whose default is UTF-8).
> Of course an alternative solution would be to just change the Calcite default
> to UTF-8 which supports encoding any UNICODE character while ISO-8859-1 can
> only encode the first 256, but I imagine there are reasons against this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5986) The typeFamily property of SqlTypeName is used inconsistently
[
https://issues.apache.org/jira/browse/CALCITE-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765821#comment-17765821
]
Julian Hyde commented on CALCITE-5986:
--
> > I think that the getFamily method should be deprecated.
> I suspect you mean use the Deprecated Java annotation. Some
> build tools are upset when you use deprecated methods, but I
> hope the build won't mind.
I mean mark it deprecated and remove all uses of it in the code, so that the
build system does not complain. If we think that {{getFamily}} is harmful,
let's stop using it.
> The typeFamily property of SqlTypeName is used inconsistently
> -
>
> Key: CALCITE-5986
> URL: https://issues.apache.org/jira/browse/CALCITE-5986
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> In SqlTypeFamily we have this code:
> {code:java}
> private static final Map JDBC_TYPE_TO_FAMILY =
> ...
> .put(Types.FLOAT, NUMERIC)
> .put(Types.REAL, NUMERIC)
> .put(Types.DOUBLE, NUMERIC)
> {code}
> But it looks to me like the type family should be APPROXIMATE_NUMERIC.
> This impacts the way RelToSqlConverter works, for instance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5979) Add REGEXP_REPLACE function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765812#comment-17765812
]
Julian Hyde edited comment on CALCITE-5979 at 9/15/23 6:58 PM:
---
Maybe the difference is in the character literals. In BigQuery character
literals, back-slash is significant. In standard SQL character literals it is
not.
To find out what is happening, can you run an experiment on BigQuery where you
call the {{REGEXP_REPLACE}} function but are not passing a character literal
with bask-slash in it. Maybe put some rows in a table, or maybe construct a
string using the {{CHR}} function.
was (Author: julianhyde):
Maybe the difference is in the character literals. In BigQuery character
literals, back-slash is significant. In standard SQL character literals it is
not.
To find out what is happening, can you run an experiment on BigQuery where you
call the {{REGEXP_REPLACE }} function but are not passing a character literal
with bask-slash in it. Maybe put some rows in a table, or maybe construct a
string using the {{CHR}} function.
> Add REGEXP_REPLACE function (enabled in BigQuery library)
> -
>
> Key: CALCITE-5979
> URL: https://issues.apache.org/jira/browse/CALCITE-5979
> Project: Calcite
> Issue Type: Task
>Reporter: Jerin John
>Assignee: Jerin John
>Priority: Major
> Labels: pull-request-available
>
> Add support for [REGEXP_REPLACE
> |https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_replace]
> function from BigQuery.
> *{{REGEXP_REPLACE(value, regexp, replacement)}}*
> Returns a STRING where all substrings of {{value}} that match regular
> expression {{regexp}} are replaced with {{{}replacement{}}}.
> backslashed-escaped digits (\1 to \9) can be used within the {{replacement}}
> argument to insert text matching the corresponding parenthesized group in the
> {{regexp}} pattern.
> Example (added one space between \ \ to override md formatting):
> {{SELECT REGEXP_REPLACE("abc'", "b(.)", "X\ \1") as result;}}
> |result|
> |aXc|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5979) Add REGEXP_REPLACE function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765812#comment-17765812
]
Julian Hyde commented on CALCITE-5979:
--
Maybe the difference is in the character literals. In BigQuery character
literals, back-slash is significant. In standard SQL character literals it is
not.
To find out what is happening, can you run an experiment on BigQuery where you
call the {{REGEXP_REPLACE }} function but are not passing a character literal
with bask-slash in it. Maybe put some rows in a table, or maybe construct a
string using the {{CHR}} function.
> Add REGEXP_REPLACE function (enabled in BigQuery library)
> -
>
> Key: CALCITE-5979
> URL: https://issues.apache.org/jira/browse/CALCITE-5979
> Project: Calcite
> Issue Type: Task
>Reporter: Jerin John
>Assignee: Jerin John
>Priority: Major
> Labels: pull-request-available
>
> Add support for [REGEXP_REPLACE
> |https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_replace]
> function from BigQuery.
> *{{REGEXP_REPLACE(value, regexp, replacement)}}*
> Returns a STRING where all substrings of {{value}} that match regular
> expression {{regexp}} are replaced with {{{}replacement{}}}.
> backslashed-escaped digits (\1 to \9) can be used within the {{replacement}}
> argument to insert text matching the corresponding parenthesized group in the
> {{regexp}} pattern.
> Example (added one space between \ \ to override md formatting):
> {{SELECT REGEXP_REPLACE("abc'", "b(.)", "X\ \1") as result;}}
> |result|
> |aXc|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6007) Sqlwith as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765809#comment-17765809
]
Julian Hyde commented on CALCITE-6007:
--
Which component generates this SQL query - SqlNode.unparse or the JDBC adapter?
Jira summary has "Sqlwith". Not sure what that means.
> Sqlwith as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5938) Update HSQLDB to Version 2.7.2
[ https://issues.apache.org/jira/browse/CALCITE-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-5938: - Fix Version/s: 1.36.0 > Update HSQLDB to Version 2.7.2 > -- > > Key: CALCITE-5938 > URL: https://issues.apache.org/jira/browse/CALCITE-5938 > Project: Calcite > Issue Type: Bug >Reporter: Shalani Weerasooriya >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > Upgrade HSQLDB to 2.7.1 to address CVE-2022-41853: > [https://nvd.nist.gov/vuln/detail/CVE-2022-41853]. > Calcite currently uses HSQLDB version 2.5.2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5938) Update HSQLDB to Version 2.7.2
[ https://issues.apache.org/jira/browse/CALCITE-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-5938: - Summary: Update HSQLDB to Version 2.7.2 (was: Update HSQLDB to Version 2.7.12) > Update HSQLDB to Version 2.7.2 > -- > > Key: CALCITE-5938 > URL: https://issues.apache.org/jira/browse/CALCITE-5938 > Project: Calcite > Issue Type: Bug >Reporter: Shalani Weerasooriya >Priority: Major > Labels: pull-request-available > > Upgrade HSQLDB to 2.7.1 to address CVE-2022-41853: > [https://nvd.nist.gov/vuln/detail/CVE-2022-41853]. > Calcite currently uses HSQLDB version 2.5.2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5974) Elasticsearch adapter throws ClassCastException when index mapping sets dynamic_templates without properties
[
https://issues.apache.org/jira/browse/CALCITE-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765807#comment-17765807
]
Julian Hyde commented on CALCITE-5974:
--
Looks good; add a unit test and I will merge.
> Elasticsearch adapter throws ClassCastException when index mapping sets
> dynamic_templates without properties
>
>
> Key: CALCITE-5974
> URL: https://issues.apache.org/jira/browse/CALCITE-5974
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: zhaowang
>Priority: Major
> Labels: pull-request-available
>
> When we use the elasticsearch-adapter, as we config an elasticsearch cluster,
> it will fetchMapping during initialization.
> If a index set dynamic_templates bug no mappings like this:
>
> {code:java}
> {
> "test_index" : {
> "mappings" : {
> "dynamic_templates" : [
> {
> "integers" : {
> "match_mapping_type" : "long",
> "mapping" : {
> "type" : "integer"
> }
> }
> }
> ]
> }
> }
> } {code}
> {{org.apache.calcite.adapter.elasticsearch.ElasticsearchJson#visitMappingProperties}}
> throw exception:
>
> {code:java}
> java.lang.ClassCastException:
> com.fasterxml.jackson.databind.node.ArrayNode cannot be cast to
> com.fasterxml.jackson.databind.node.ObjectNode
> at
>
> org.apache.calcite.adapter.elasticsearch.ElasticsearchJson.visitMappingProperties(ElasticsearchJson.java:133)
> {code}
> So ElasticsearchTransport initialize failed, all index of this es cluster
> access failed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5978) Add REGEXP_INSTR function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary resolved CALCITE-5978.
---
Fix Version/s: 1.36.0
Resolution: Fixed
Merged via
[9e3ea96|https://github.com/apache/calcite/commit/9e3ea965044e477416189fa07423433aa51b0ae1],
thanks for the fix, [~jerin_john]!
> Add REGEXP_INSTR function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-5978
> URL: https://issues.apache.org/jira/browse/CALCITE-5978
> Project: Calcite
> Issue Type: Task
>Reporter: Jerin John
>Assignee: Jerin John
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Add support for [REGEXP_INSTR
> |https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_instr]
> function from BigQuery.
> *{{REGEXP_INSTR(string, regexp [, position [, occurrence [,
> occurrence_position]]])}}*
> Returns the lowest 1-based position of the substring in {{string}} that
> matches the {{{}regexp{}}}, Returns 0 if there is no match
> * If {{position}} is specified, the search starts at this position in
> {{{}string{}}}, otherwise it starts at the beginning of {{{}string{}}}.
> * If {{occurrence}} is specified, the search returns index for the specific
> occurrence of the {{regexp}} in value, otherwise returns the first match.
> * If {{occurrence_position}} is specified as 1, returns the end index of
> substring + 1 (default 0 returns start index of match)
> Example:
> {{SELECT REGEXP_INSTR("abcadcabcaecghi", "adc") as result;}}
> |result|
> |4|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765469#comment-17765469 ] Leonid Chistov commented on CALCITE-5957: - [~zstan] Sorry, don't know why it happened, it was not intentional. > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Blocker > Labels: pull-request-available > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonid Chistov reassigned CALCITE-5957: --- Assignee: Evgeny Stanilovsky (was: Leonid Chistov) > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Blocker > Labels: pull-request-available > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-5974) Elasticsearch adapter throws ClassCastException when index mapping sets dynamic_templates without properties
[
https://issues.apache.org/jira/browse/CALCITE-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhaowang reassigned CALCITE-5974:
-
Assignee: (was: zhaowang)
> Elasticsearch adapter throws ClassCastException when index mapping sets
> dynamic_templates without properties
>
>
> Key: CALCITE-5974
> URL: https://issues.apache.org/jira/browse/CALCITE-5974
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: zhaowang
>Priority: Major
> Labels: pull-request-available
>
> When we use the elasticsearch-adapter, as we config an elasticsearch cluster,
> it will fetchMapping during initialization.
> If a index set dynamic_templates bug no mappings like this:
>
> {code:java}
> {
> "test_index" : {
> "mappings" : {
> "dynamic_templates" : [
> {
> "integers" : {
> "match_mapping_type" : "long",
> "mapping" : {
> "type" : "integer"
> }
> }
> }
> ]
> }
> }
> } {code}
> {{org.apache.calcite.adapter.elasticsearch.ElasticsearchJson#visitMappingProperties}}
> throw exception:
>
> {code:java}
> java.lang.ClassCastException:
> com.fasterxml.jackson.databind.node.ArrayNode cannot be cast to
> com.fasterxml.jackson.databind.node.ObjectNode
> at
>
> org.apache.calcite.adapter.elasticsearch.ElasticsearchJson.visitMappingProperties(ElasticsearchJson.java:133)
> {code}
> So ElasticsearchTransport initialize failed, all index of this es cluster
> access failed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
