[jira] [Updated] (CALCITE-6515) Remove constants describing which bugs have been fixed in Bug
[
https://issues.apache.org/jira/browse/CALCITE-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6515:
Labels: pull-request-available (was: )
> Remove constants describing which bugs have been fixed in Bug
> -
>
> Key: CALCITE-6515
> URL: https://issues.apache.org/jira/browse/CALCITE-6515
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Priority: Minor
> Labels: pull-request-available
>
> The constants in Bug.java:
> {code:java}
> /** Whether
> * https://issues.apache.org/jira/browse/CALCITE-6375;>[CALCITE-6375]
> * Fix failing quidem tests for FORMAT in CAST is fixed. */
> public static final boolean CALCITE_6375_FIXED = false; {code}
> {code:java}
> /** Whether * href="https://issues.apache.org/jira/browse/CALCITE/issues/CALCITE-6295;> *
> [CALCITE-6295] Support IS NOT NULL in Arrow adapter is fixed. */ public
> static final boolean CALCITE_6295_FIXED = false;
> {code}
> {code:java}
> /** Whether
> * https://issues.apache.org/jira/browse/CALCITE/issues/CALCITE-6296;>
> * [CALCITE-6296] Support IS NULL in Arrow adapter is fixed. */
> public static final boolean CALCITE_6296_FIXED = false;{code}
> These bugs have been fixed, so need to remove it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6514) Enable tests about AssertionError while translating IN list that contains null
[
https://issues.apache.org/jira/browse/CALCITE-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6514:
Labels: pull-request-available (was: )
> Enable tests about AssertionError while translating IN list that contains null
> --
>
> Key: CALCITE-6514
> URL: https://issues.apache.org/jira/browse/CALCITE-6514
> Project: Calcite
> Issue Type: Improvement
>Reporter: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> /**
> * Whether http://issues.eigenbase.org/browse/FRG-327;>issue
> * FRG-327: AssertionError while translating IN list that contains null
> * is fixed.
> */
> public static final boolean FRG327_FIXED = false; {code}
> After the test, this issue has been fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6465) Rework code generator
[ https://issues.apache.org/jira/browse/CALCITE-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6465: Labels: pull-request-available (was: ) > Rework code generator > - > > Key: CALCITE-6465 > URL: https://issues.apache.org/jira/browse/CALCITE-6465 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: James Duong >Assignee: James Duong >Priority: Major > Labels: pull-request-available > > Holistically replace the (or provide a separate optional) code generator to > reduce issues such as CALCITE-3094 . > One suggestion in the comments for CALCITE-3094 has been to use the [code > generator from > Flink.|https://nightlies.apache.org/flink/flink-docs-release-1.3/api/java/org/apache/flink/table/codegen/CodeGenerator.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6513) FilterProjectTransposeRule may cause OOM when Project expressions are complex
[
https://issues.apache.org/jira/browse/CALCITE-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6513:
Labels: pull-request-available (was: )
> FilterProjectTransposeRule may cause OOM when Project expressions are complex
> -
>
> Key: CALCITE-6513
> URL: https://issues.apache.org/jira/browse/CALCITE-6513
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Krisztian Kasa
>Assignee: Krisztian Kasa
>Priority: Major
> Labels: pull-request-available
>
> CALCITE-3774 addresses preventing merging projects when the resulting
> expressions in the merged project are too complex and lead to slow
> compilation or out of memory.
> However, when there is a {{Filter}} on top of the {{Projects}} with a
> predicate referencing the complex expressions {{FilterProjectTransposeRule}}
> tries to push down the {{Filter}} below the bottom {{Project}} merging the
> expressions and causing OOM.
> The issue was initially reproduced using Hive with the Hive version of
> {{FilterProjectTransposeRule}}. See: HIVE-28264
> Calcite is also affected:
> [https://github.com/kasakrisz/calcite/commit/b35a02f368624a9c4768f348cd072a95ed6de3e1]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6506) Incorrect RelDataType generated for IN Subquery
[
https://issues.apache.org/jira/browse/CALCITE-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6506:
Labels: pull-request-available (was: )
> Incorrect RelDataType generated for IN Subquery
> ---
>
> Key: CALCITE-6506
> URL: https://issues.apache.org/jira/browse/CALCITE-6506
> Project: Calcite
> Issue Type: Bug
>Reporter: Brandon Chong
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> If a user writes a query like:
>
> {{select * from cp."iceberg/orders/orders.parquet" where o_orderkey IN (1,
> 2, 3)}}
> It get's rewritten to use a LogicalValues with RelDataType nullable INTEGER
> row type. The problem is that it's actually NOT NULL.
> You can see the issue in SqlToRelConverter:
>
> {{final RelDataType targetRowType =
> SqlTypeUtil.promoteToRowType(typeFactory,
> validator.getValidatedNodeType(leftKeyNode), null);
> final boolean notIn = call.getOperator().kind == SqlKind.NOT_IN;
> converted =
> convertExists(query, RelOptUtil.SubQueryType.IN, subQuery.logic,
> notIn, targetRowType);}}
> Note that it's using the type of the leftKeyNode and not right key node.
> For example: A IN (B, C, D) ... it's using typeof(A) instead of typeof(B, C,
> D).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6496) Enable tests from outer.iq
[
https://issues.apache.org/jira/browse/CALCITE-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6496:
Labels: pull-request-available (was: )
> Enable tests from outer.iq
> --
>
> Key: CALCITE-6496
> URL: https://issues.apache.org/jira/browse/CALCITE-6496
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> Many tests in outer.iq are disabled with this comment:
> {code}
> # The following test is disabled, because we cannot handle non-equi-join.
> # Following it are the results from MySQL.
> !if (false) {
> {code}
> Most of these tests could probably be enabled, but they require minor
> formatting.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6511) Migrate from Gradle Enterprise Gradle Plugin to Develocity Gradle Plugin
[ https://issues.apache.org/jira/browse/CALCITE-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6511: Labels: pull-request-available (was: ) > Migrate from Gradle Enterprise Gradle Plugin to Develocity Gradle Plugin > - > > Key: CALCITE-6511 > URL: https://issues.apache.org/jira/browse/CALCITE-6511 > Project: Calcite > Issue Type: Improvement >Reporter: Clay Johnson >Assignee: Clay Johnson >Priority: Minor > Labels: pull-request-available > > Currently, Calcite publishes build scans to the Develocity instance at > ge.apache.org. To accomplish this, the Gradle Enterprise Gradle Plugin is > applied. > As of Develocity 2024.3, expected later this year, the Gradle Enterprise > Gradle Plugin will no longer be supported. Migration to the Develocity Gradle > Plugin will be necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6480) OracleDialect does not support CASE WHEN returning boolean
[
https://issues.apache.org/jira/browse/CALCITE-6480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6480:
Labels: pull-request-available (was: )
> OracleDialect does not support CASE WHEN returning boolean
> --
>
> Key: CALCITE-6480
> URL: https://issues.apache.org/jira/browse/CALCITE-6480
> Project: Calcite
> Issue Type: Wish
> Components: core
>Reporter: kate
>Priority: Minor
> Labels: pull-request-available
>
> Our requirement is to use Calcite to translate queries into different
> dialects. During validation in the TPC-DS scenario, we found that {{Oracle}}
> does not support SQL statements like
> {code:java}
> SELECT * FROM xxx
> WHERE CASE WHEN a > 10 THEN b < 5 ELSE c > 0 END;{code}
> Therefore, we hope to remove such predicates at the dialect like Oracle.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6509) MongoAdapter throws 'Invalid JSON Number' exception if first character of field name is number
[
https://issues.apache.org/jira/browse/CALCITE-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6509:
Labels: pull-request-available (was: )
> MongoAdapter throws 'Invalid JSON Number' exception if first character of
> field name is number
> --
>
> Key: CALCITE-6509
> URL: https://issues.apache.org/jira/browse/CALCITE-6509
> Project: Calcite
> Issue Type: Bug
> Components: mongodb-adapter
>Affects Versions: 1.37.0
>Reporter: Dmitry Sysolyatin
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Labels: pull-request-available
>
> MongoAdapter throws 'Invalid JSON Number' exception if first character of
> field name is number.
> Test case:
> {code}
> assertModel(MODEL)
> .query("select cast(_MAP['1_minute_aggregation'] as INT) as
> \"1_minute_aggregation\" "
> + "from \"mongo_raw\".\"datatypes\"")
> .queryContains(
> mongoChecker("{$project: {'1_minute_aggregation': 1}}"));
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5034) Disable Gradle build cache or use an alternative account for it
[ https://issues.apache.org/jira/browse/CALCITE-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5034: Labels: pull-request-available (was: ) > Disable Gradle build cache or use an alternative account for it > --- > > Key: CALCITE-5034 > URL: https://issues.apache.org/jira/browse/CALCITE-5034 > Project: Calcite > Issue Type: Task > Components: build >Reporter: Vladimir Sitnikov >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Attachments: bucket-utilization-cache.csv > > > Calcite uses build cache since CALCITE-4140. > I'm paying for the service (~$6/month), and there's a risk bank will block > further payments (I'm from Russia :-/ ), so I think it is time to switch to > another account or disable the build-cache. > I've chosen Wasabi S3 since they have a free egress policy, so the costs are > predictable. > Cloudflare R2 is not ready yet: > https://blog.cloudflare.com/introducing-r2-object-storage/ > Rough stats so far > Total storage=15 GiB (~retention is 30 days) > Upload=0.1-0.2 GiB/day > Download=1-2 GiB/day -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6507) Random functions are incorrectly considered deterministic
[
https://issues.apache.org/jira/browse/CALCITE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6507:
Labels: pull-request-available (was: )
> Random functions are incorrectly considered deterministic
> -
>
> Key: CALCITE-6507
> URL: https://issues.apache.org/jira/browse/CALCITE-6507
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> {{{}RAND{}}}, {{{}RANDOM{}}}, and {{RAND_INTEGER}} don't override the
> {{isDeterministic}} method, so they get the default behavior, i.e. true,
> which is incorrect.
> This can lead to undesired consequences, e.g.:
> A) {{RelMetadataQuery#getPulledUpPredicates}} can consider them as constants
> (and place them inside {{{}RelOptPredicateList#constantMap{}}}) since
> {{RelMdPredicates}} calls {{{}RexUtil#isConstant{}}}, which uses a
> {{ConstantFinder}} that evaluates whether a RexCall is constant or not based
> on the operator's isDeterministic value.
> B) As a consequence of A) {{SortRemoveConstantKeyRule}} can incorrectly
> remove an "ORDER BY RAND()"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6478) JSON functions should return NULL when input is NULL
[
https://issues.apache.org/jira/browse/CALCITE-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6478:
Labels: pull-request-available (was: )
> JSON functions should return NULL when input is NULL
> -
>
> Key: CALCITE-6478
> URL: https://issues.apache.org/jira/browse/CALCITE-6478
> Project: Calcite
> Issue Type: Improvement
>Reporter: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> Here is the test in H2:
> {code:java}
> SELECT js,
>js IS JSON"json?",
>js IS JSON value "json?",
>js IS JSON SCALAR "scalar?",
>js IS JSON OBJECT "object?",
>js IS JSON ARRAY "array?"
> FROM (VALUES ('123'),
> ('"abc"'),
> ('{"a": "b"}'),
> ('[1,2]'),
> ('abc'), NULL) foo(js);
> {code}
> {code:java}
> +--+-+-+---+---+--+
> |JS|json?|json?|scalar?|object?|array?|
> +--+-+-+---+---+--+
> |123 |true |true |true |false |false |
> |"abc" |true |true |true |false |false |
> |{"a": "b"}|true |true |false |true |false |
> |[1,2] |true |true |false |false |true |
> |abc |false|false|false |false |false |
> |null |null |null |null |null |null |
> +--+-+-+---+---+--+
> {code}
> Same SQL in Calcite:
> {code:java}
> ++---+---+-+-++
> | JS | json? | json? | scalar? | object? | array? |
> ++---+---+-+-++
> | "abc" | true | true | true| false | false |
> | 123| true | true | true| false | false |
> | [1,2] | true | true | false | false | true |
> | abc| false | false | false | false | false |
> | {"a": "b"} | true | true | false | true| false |
> || false | false | false | false | false |
> ++---+---+-+-++
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6481) Optimize 'VALUES...UNION ALL...VALUES' to a single 'VALUES' the IN-list contains NULL and it is converted to VALUES
[
https://issues.apache.org/jira/browse/CALCITE-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6481:
Labels: pull-request-available (was: )
> Optimize 'VALUES...UNION ALL...VALUES' to a single 'VALUES' the IN-list
> contains NULL and it is converted to VALUES
> ---
>
> Key: CALCITE-6481
> URL: https://issues.apache.org/jira/browse/CALCITE-6481
> Project: Calcite
> Issue Type: Improvement
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> The SQL:
> {code:java}
> with
> t1(a,y) as (select * from (values (1, 2), (3,
> null),(7369,null),(7499,30),(null, 20),(null, 5)) as t1)
> select *
> from t1
> where (t1.a,t1.y) in ((1, 2), (3, null),(7369,null),(7499,30),(null,
> 20),(null, 5));
> EnumerableHashJoin(condition=[AND(=($0, $2), =($1, $3))], joinType=[semi])
> EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }, { 7369, null }, { 7499, 30
> }, { null, 20 }, { null, 5 }]])
> EnumerableUnion(all=[true])
> EnumerableValues(tuples=[[{ 3, null }]])
> EnumerableValues(tuples=[[{ 7369, null }]])
> EnumerableValues(tuples=[[{ null, 20 }]])
> EnumerableValues(tuples=[[{ null, 5 }]])
> EnumerableValues(tuples=[[{ 1, 2 }, { 7499, 30 }]])
> !plan
> with
> t1(a,y) as (select * from (values (1, 2), (3, 5),(7369,6),(7499,30),(2,
> 20),(3, 5)) as t1)
> select *
> from t1
> where (t1.a,t1.y) in ((1, 2), (3, 3),(7369,3),(7499,30),(1, 20),(3, 5));
> EnumerableHashJoin(condition=[AND(=($0, $2), =($1, $3))], joinType=[semi])
> EnumerableValues(tuples=[[{ 1, 2 }, { 3, 5 }, { 7369, 6 }, { 7499, 30 }, {
> 2, 20 }, { 3, 5 }]])
> EnumerableValues(tuples=[[{ 1, 2 }, { 3, 3 }, { 7369, 3 }, { 7499, 30 }, {
> 1, 20 }, { 3, 5 }]])
> !plan {code}
> If the IN-list includes NULL, Calcite will convert VALUES to UNION ALL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6502) Parser loses position information for Expression3
[
https://issues.apache.org/jira/browse/CALCITE-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6502:
Labels: pull-request-available (was: )
> Parser loses position information for Expression3
> -
>
> Key: CALCITE-6502
> URL: https://issues.apache.org/jira/browse/CALCITE-6502
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> Parser.jj features the following code snipped in the Expression3 production:
> {code:java}
> if (list1.size() == 1) {
> // interpret as single value or query
> return list1.get(0);
> }
> {code}
> This is problematic because the span of list1 is not the same as the span of
> its first element.
> This makes it look like the expression parsed does not include the opening
> and closing parens.
> This can be a problem for error reporting tools (but there are other use
> cases that may be impacted).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6498) Elasticsearch multi-field mappings do not work
[
https://issues.apache.org/jira/browse/CALCITE-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6498:
Labels: pull-request-available (was: )
> Elasticsearch multi-field mappings do not work
> --
>
> Key: CALCITE-6498
> URL: https://issues.apache.org/jira/browse/CALCITE-6498
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Reporter: Tim Grein
>Assignee: Tim Grein
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> _EmbeddedElasticsearchPolicy#_
> _applyMapping_ tries to apply a multi-field mapping by adding another
> _properties_ field inside a parent field mapping. In Elasticsearch you need
> to use _fields_ rather than _properties_ for a multi-field mapping to work.
>
> I've tested this with ES 7 and ES 6 (only including ES 7 example here in the
> issue description; for ES 6 you need to wrap everything under "mappings" in
> "_doc"):
> ES 7:
> {code:java}
> PUT /some_index
> {
> "mappings": {
> "properties": {
> "some_field": {
> "type": "text",
> "properties": {
> "keyword": {
> "type": "keyword"
> }
> }
> }
> }
> }
> }{code}
> will lead to the following error:
> {code:java}
> {
> "error" : {
> "root_cause" : [
> {
> "type" : "mapper_parsing_exception",
> "reason" : "Mapping definition for [some_field] has unsupported
> parameters: [properties : {keyword={type=keyword}}]"
> }
> ],
> "type" : "mapper_parsing_exception",
> "reason" : "Failed to parse mapping [_doc]: Mapping definition for
> [some_field] has unsupported parameters: [properties :
> {keyword={type=keyword}}]",
> "caused_by" : {
> "type" : "mapper_parsing_exception",
> "reason" : "Mapping definition for [some_field] has unsupported
> parameters: [properties : {keyword={type=keyword}}]"
> }
> },
> "status" : 400
> } {code}
>
> Successful request:
> {code:java}
> PUT /some_index
> {
> "mappings": {
> "properties": {
> "some_field": {
> "type": "text",
> "fields": {
> "keyword": {
> "type": "keyword"
> }
> }
> }
> }
> }
> } {code}
> You'll encounter this error also, if you adapt the test data in
> _ElasticsearchAdapterTest_ to include nested fields:
> {code:java}
> @BeforeAll
> public static void setupInstance() throws Exception {
> // "city.keyword" is a nested field with type "keyword"
> final Map mapping =
> ImmutableMap.of("city", "text", "city.keyword", "keyword", "state",
> "keyword", "pop", "long"); {code}
> Error:
> {code:java}
> {...
> {"type":"mapper_parsing_exception","reason":"unknown parameter [properties]
> on mapper [city] of type [text]"}
> ...} {code}
> Looking at _ElasticsearchJson#visitMappingProperties_ I assume this will lead
> to a similar issue, which I'll double-check (we probably need to distinguish
> between nested fields and multi-field mappings explicitly).
> This is related to https://issues.apache.org/jira/browse/CALCITE-3027 as you
> want to detect, if you perform a "LIKE" operator on a purely "text" mapped
> field, which will lead to weird semantics ("text" mapped fields are
> analyzed/broken up into several tokens), if you do not prevent it. Usually
> you have a multi-field mapping for a field containing text ("text" mapping
> for full text search and a "keyword" mapping you can use for aggregations,
> wildcard queries etc.). So this is rather important to work correctly overall
> and in the tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6471) Improve performance of SqlToRelConverter by preventing unconditional conversion of sqlNodes to string for null-check messages
[
https://issues.apache.org/jira/browse/CALCITE-6471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6471:
Labels: pull-request-available (was: )
> Improve performance of SqlToRelConverter by preventing unconditional
> conversion of sqlNodes to string for null-check messages
> --
>
> Key: CALCITE-6471
> URL: https://issues.apache.org/jira/browse/CALCITE-6471
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Minor
> Labels: pull-request-available
>
> Currently, {{SqlToRelConverter}} contains a few places where {{sqlNode}} is
> concatenated to some prefix and passed as plain string rather that message
> supplier as parameter to {{requireNonNull}} method. These are, namely, lines
> 1019, 4031, and 5344 at commit 29c413a3:
> {code:java}
> SqlNode elseOperand =
> requireNonNull(caseNode.getElseOperand(),
> "getElseOperand for " + caseNode);
> {code}
> {code:java}
> protected RelOptTable getTargetTable(SqlNode call) {
> final SqlValidatorNamespace targetNs = getNamespace(call);
> SqlValidatorNamespace namespace;
> if (targetNs.isWrapperFor(SqlValidatorImpl.DmlNamespace.class)) {
> namespace = targetNs.unwrap(SqlValidatorImpl.DmlNamespace.class);
> } else {
> namespace = targetNs.resolve();
> }
> RelOptTable table = SqlValidatorUtil.getRelOptTable(namespace,
> catalogReader, null, null);
> return requireNonNull(table, "no table found for " + call);
> }
> {code}
> {code:java}
> return Pair.of(c, (e, fieldName) -> {
> final int j = requireNonNull(fieldMap.get(fieldName), "field " +
> fieldName);
> return rexBuilder.makeFieldAccess(e, j);
> });
> {code}
> We can shave a few microseconds by simply replacing plain string with message
> supplier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6372) Support ASOF joins
[ https://issues.apache.org/jira/browse/CALCITE-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6372: Labels: pull-request-available (was: ) > Support ASOF joins > -- > > Key: CALCITE-6372 > URL: https://issues.apache.org/jira/browse/CALCITE-6372 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > Seems that this new kind of JOIN named AS OF is very useful for processing > time-series data. Here is some example documentation from Snowflake: > https://docs.snowflake.com/en/sql-reference/constructs/asof-join > The semantics is similar to a traditional join, but the result always > contains at most one record from the left side, with the last matching > record on the right side (where "time" is any value that can be compared for > inequality). This can be expressed in SQL, but it looks very cumbersome, > using a JOIN, a GROUP BY, and then an aggregation to keep the last value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6497) Use helper setup method throughout whole ElasticsearchAdapterTest
[ https://issues.apache.org/jira/browse/CALCITE-6497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6497: Labels: pull-request-available (was: ) > Use helper setup method throughout whole ElasticsearchAdapterTest > - > > Key: CALCITE-6497 > URL: https://issues.apache.org/jira/browse/CALCITE-6497 > Project: Calcite > Issue Type: Improvement > Components: tests >Affects Versions: 1.37.0 >Reporter: Tim Grein >Assignee: Tim Grein >Priority: Trivial > Labels: pull-request-available > Fix For: 1.38.0 > > > There's a helper method `calciteAssert` inside the > `ElasticsearchAdapterTest`, which is responsible for setting up a connection > to Elasticsearch. This helper method is not used throughout the test class > consistently, which leads to code duplication and some manual setup code. We > should use the helper method to keep things consistent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6495) Allow ProjectSetOpTransposeRule to work with any subclass of Project
[
https://issues.apache.org/jira/browse/CALCITE-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6495:
Labels: pull-request-available (was: )
> Allow ProjectSetOpTransposeRule to work with any subclass of Project
>
>
> Key: CALCITE-6495
> URL: https://issues.apache.org/jira/browse/CALCITE-6495
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> Even if the default configuration of ProjectSetOpTransposeRule matches a
> LogicalProject, theoretically any downstream project could adjust the rule
> config to match a different subclass of Project, with the corresponding
> RelBuilderFactory, to obtain the rule behavior customized for their needs.
> However, at this point this cannot work because
> ProjectSetOpTransposeRule#onMatch performs a
> {code:java}
> final LogicalProject origProject = call.rel(0);
> {code}
> which leads to a {{ClassCastException}} in this scenario.
> Therefore, this line should be changed (and generalized) into
> {code:java}
> final Project origProject = call.rel(0);
> {code}
> (as it happens already in other rules, such as FilterSetOpTransposeRule or
> ProjectFilterTransposeRule) to improve the rule's adaptability, without
> impacting the rule's behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6493) Improve Calcite development documentation
[ https://issues.apache.org/jira/browse/CALCITE-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6493: Labels: pull-request-available (was: ) > Improve Calcite development documentation > - > > Key: CALCITE-6493 > URL: https://issues.apache.org/jira/browse/CALCITE-6493 > Project: Calcite > Issue Type: Improvement > Components: site >Affects Versions: 1.37.0 >Reporter: Caican Cai >Priority: Minor > Labels: pull-request-available > > I noticed that in the jira submission process (like me), some terms are not > standardized, such as Mysql -> MySQL, arrow -> Spark. Thanks Julian for the > reminder > I think we can explain it in the document -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6490) Missing tests for SqlFunctions#overlay
[ https://issues.apache.org/jira/browse/CALCITE-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6490: Labels: pull-request-available (was: ) > Missing tests for SqlFunctions#overlay > -- > > Key: CALCITE-6490 > URL: https://issues.apache.org/jira/browse/CALCITE-6490 > Project: Calcite > Issue Type: Improvement > Components: tests >Affects Versions: 1.37.0 >Reporter: Tim Grein >Assignee: Tim Grein >Priority: Minor > Labels: pull-request-available > Fix For: 1.38.0 > > > After making some improvements to the OVERLAY operator docs in [Fix error > message typo and improve docs for OVERLAY > operator|https://github.com/apache/calcite/pull/3877] I've noticed that there > are no tests for SqlFunctions#overlay in SqlFunctionsTest. As checkString in > SqlOperatorTest doesn't check the actual value against the expected result > (at least that's how I understood it) I thought it's even more important to > add tests for the OVERLAY operator in SqlFunctionsTest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6489) Add more data types to the Arrow test set
[ https://issues.apache.org/jira/browse/CALCITE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6489: Labels: pull-request-available (was: ) > Add more data types to the Arrow test set > - > > Key: CALCITE-6489 > URL: https://issues.apache.org/jira/browse/CALCITE-6489 > Project: Calcite > Issue Type: Sub-task >Reporter: Caican Cai >Priority: Major > Labels: pull-request-available > > Currently, the Arrow test set only has basic data types, such as int, long, > etc., but does not have smallInt, tinyint, etc. > It is possible to improve the Arrow test set -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6488) Ensure collations created by RelCollations are canonized once
[ https://issues.apache.org/jira/browse/CALCITE-6488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6488: Labels: pull-request-available (was: ) > Ensure collations created by RelCollations are canonized once > - > > Key: CALCITE-6488 > URL: https://issues.apache.org/jira/browse/CALCITE-6488 > Project: Calcite > Issue Type: Task > Components: core >Affects Versions: 1.37.0 >Reporter: Ruben Q L >Assignee: Ruben Q L >Priority: Minor > Labels: pull-request-available > Fix For: 1.38.0 > > > RelCollations#of canonizes internally the result before returning it; however > some callers unnecessarily re-canonize the result on their end. > RelCollations#shift does not canonize its result, some callers canonize on > their end while others don't. > It is proposed to align their behaviour: RelCollations#of and > RelCollations#shift will canonize internally their results before return, so > that their callers do not need to do it on their end. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6485) AssertionError When an IN list containing NULL has an implicit coercion type converter
[
https://issues.apache.org/jira/browse/CALCITE-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6485:
Labels: pull-request-available (was: )
> AssertionError When an IN list containing NULL has an implicit coercion type
> converter
> --
>
> Key: CALCITE-6485
> URL: https://issues.apache.org/jira/browse/CALCITE-6485
> Project: Calcite
> Issue Type: Improvement
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> @Test void testInOperation() {
> sql("select 1 in (null, '2', '3') as f0 from (values (true, true,
> true))").ok();
> }
> {code}
> {code:java}
> Conversion to relational algebra failed to preserve datatypes:
> validated type:
> RecordType(BOOLEAN NOT NULL F0) NOT NULL
> converted type:
> RecordType(BOOLEAN F0) NOT NULL
> rel:
> LogicalValues(tuples=[[{ null }]]) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6487) TRIM function documentation refers to string1 two times
[
https://issues.apache.org/jira/browse/CALCITE-6487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6487:
Labels: newbie pull-request-available (was: newbie)
> TRIM function documentation refers to string1 two times
> ---
>
> Key: CALCITE-6487
> URL: https://issues.apache.org/jira/browse/CALCITE-6487
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Tim Grein
>Assignee: Tim Grein
>Priority: Trivial
> Labels: newbie, pull-request-available
>
> The docs for 'TRIM' state the following:
> "Removes the longest string containing only the characters in _string1_ from
> the start/end/both ends of _string1."_
>
> It should be the following to be accurate (changed last word from _string1_
> to {_}string2{_}):
> "Removes the longest string containing only the characters in _string1_ from
> the start/end/both ends of _string2."_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6145) Function 'TRIM' without parameters throw NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6145:
Labels: newbie pull-request-available (was: newbie)
> Function 'TRIM' without parameters throw NullPointerException
> -
>
> Key: CALCITE-6145
> URL: https://issues.apache.org/jira/browse/CALCITE-6145
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: SimonAlexs
>Assignee: Tim Grein
>Priority: Major
> Labels: newbie, pull-request-available
>
> When use sql as follow, trim without parameters, it throws
> java.lang.NullPointerException.
> {code:java}
> select trim(){code}
> Error position is org.apache.calcite.sql.SqlOperator#constructArgNameList.
> Source code is below. Line 5 "operand.getKind()" results in this exception.
>
> {code:java}
> protected @Nullable List constructArgNameList(SqlCall call) {
> // If any arguments are named, construct a map.
> final ImmutableList.Builder nameBuilder = ImmutableList.builder();
> for (SqlNode operand : call.getOperandList()) {
> if (operand.getKind() == SqlKind.ARGUMENT_ASSIGNMENT) {
> final List operandList = ((SqlCall) operand).getOperandList();
> nameBuilder.add(((SqlIdentifier) operandList.get(1)).getSimple());
> }
> }
> ImmutableList argNames = nameBuilder.build();
> if (argNames.isEmpty()) {
> return null;
> } else {
> return argNames;
> }
> } {code}
>
> Should it throw an exact description?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6295) Support IS NOT NULL in Arrow adapter
[
https://issues.apache.org/jira/browse/CALCITE-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6295:
Labels: pull-request-available (was: )
> Support IS NOT NULL in Arrow adapter
>
>
> Key: CALCITE-6295
> URL: https://issues.apache.org/jira/browse/CALCITE-6295
> Project: Calcite
> Issue Type: Sub-task
> Components: arrow-adapter
>Reporter: hongyu guo
>Assignee: Tim Grein
>Priority: Major
> Labels: pull-request-available
>
> For example:
> {code:sql}
> select "intField", "stringField"
> from arrowdata
> where "intField" is not null
> order by "intField"
> limit 1
> {code}
> will throw an exception
> {code:java}
> java.lang.AssertionError: cannot translate IS NOT NULL($0)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateMatch2(ArrowTranslator.java:131)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateAnd(ArrowTranslator.java:111)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateMatch(ArrowTranslator.java:68)
> at
> org.apache.calcite.adapter.arrow.ArrowFilter.(ArrowFilter.java:43)
> at
> org.apache.calcite.adapter.arrow.ArrowRules$ArrowFilterRule.convert(ArrowRules.java:97)
> at
> org.apache.calcite.adapter.arrow.ArrowRules$ArrowFilterRule.onMatch(ArrowRules.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6475) RelToSql converter fails when the IN-list contains NULL and it is converted to VALUES
[
https://issues.apache.org/jira/browse/CALCITE-6475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6475:
Labels: pull-request-available (was: )
> RelToSql converter fails when the IN-list contains NULL and it is converted
> to VALUES
> -
>
> Key: CALCITE-6475
> URL: https://issues.apache.org/jira/browse/CALCITE-6475
> Project: Calcite
> Issue Type: Bug
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> The SQL
> {code:java}
> select * from "product" where ("product_id") in (12, null){code}
> When we convert the IN-list to OR condition, it can run successfully. But
> when we convert it to VALUES, it will throw NPE:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.toSql(SqlImplementor.java:1468)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.toSql(SqlImplementor.java:1416)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor$Context.toSql(SqlImplementor.java:702)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.lambda$exprList$17(RelToSqlConverter.java:1158){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6483) Add length to PostgreSQL function library
[ https://issues.apache.org/jira/browse/CALCITE-6483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6483: Labels: pull-request-available (was: ) > Add length to PostgreSQL function library > - > > Key: CALCITE-6483 > URL: https://issues.apache.org/jira/browse/CALCITE-6483 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Norman Jordan >Assignee: Norman Jordan >Priority: Minor > Labels: pull-request-available > > PostgreSQL supports the *LENGTH* string function. > [https://www.postgresql.org/docs/14/functions-string.html] > Also check other libraries to see if those functions should be included. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6484) Sonar analysis fails intermittently due to OOM
[
https://issues.apache.org/jira/browse/CALCITE-6484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6484:
Labels: pull-request-available (was: )
> Sonar analysis fails intermittently due to OOM
> --
>
> Key: CALCITE-6484
> URL: https://issues.apache.org/jira/browse/CALCITE-6484
> Project: Calcite
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.37.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
>
> Sometimes the Sonar analysis fails due to OOM, here an [example of CI
> logs|https://ci-builds.apache.org/blue/organizations/jenkins/Calcite%2FCalcite-sonar/detail/PR-3858/9/pipeline/].
> In what follows the relevant extract:
> {code:java}
> The Daemon will expire after the build after running out of JVM heap space.
> The project memory settings are likely not configured or are configured to an
> insufficient value.
> The daemon will restart for the next build, which may increase subsequent
> build times.
> These settings can be adjusted by setting 'org.gradle.jvmargs' in
> 'gradle.properties'.
> The currently configured max heap space is '1 GiB' and the configured max
> metaspace is '512 MiB'.
> For more information on how to set these values, please refer to
> https://docs.gradle.org/8.7/userguide/build_environment.html#sec:configuring_jvm_memory
> in the Gradle documentation.
> To disable this warning, set
> 'org.gradle.daemon.performance.disable-logging=true'.
> > Task :sonar FAILED
> Build calcite FAILURE reason:
> Execution failed for task ':sonar':
> java.lang.OutOfMemoryError: Java heap space
> at B.A.A.A.A.F.(na:2438)
> at B.A.A.A.A.D$_D.(na:1146)
> at B.A.A.A.A.D.iterator(na:1079)
> at com.sonarsource.A.A.E.G$_C.D(na:2233)
> at com.sonarsource.A.A.C.E.A(na:972)
> at com.sonarsource.A.A.C.E.C(na:2276)
> at com.sonarsource.A.A.C.E.B(na:3115)
> at com.sonarsource.A.A.Y.A(na:3332)
> at com.sonarsource.A.A.Y.A(na:2596)
> at com.sonarsource.A.A.Y.E(na:1668)
> at com.sonarsource.A.A.Y.A(na:943)
> at com.sonarsource.A.A.Y.A(na:377)
> at com.sonarsource.A.A.Y.A(na:2750)
> at com.sonarsource.A.H.executeChecksOnFunction(na:1449)
> at com.sonarsource.A.H.executeChecks(na:2587)
> at com.sonarsource.A.H.executeSensor(na:3171)
> at com.sonarsource.A.H.execute(na:1926)
> at
> org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:63)
> at
> org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:75)
> at
> org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:51)
> at
> org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:64)
> at
> org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
> at
> org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
> at
> org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:192)
> at
> org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:188)
> at
> org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:159)
> at
> org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
> at
> org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
> at
> org.sonar.scanner.bootstrap.ScannerContainer.doAfterStart(ScannerContainer.java:399)
> at
> org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
> at
> org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
> at
> org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:131)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':sonar'.
> > Java heap space {code}
> At the top of the quoted text, it's recommended to increase the memory
> settings via the parameter 'org.gradle.jvmargs' in 'gradle.properties'.
> Since most of the time the analysis succeeds, we probably need a small
> increment at first to see if the situation improves (max heap space is now '1
> GiB', max metaspace is '512 MiB').
> It's detrimental to have CI failures as they not only deprive us from the
> sonar analysis, but they also contributed to the sentiment that flakyness in
>
[jira] [Updated] (CALCITE-6482) OracleDialect support bool literal as predicate
[ https://issues.apache.org/jira/browse/CALCITE-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6482: Labels: pull-request-available (was: ) > OracleDialect support bool literal as predicate > --- > > Key: CALCITE-6482 > URL: https://issues.apache.org/jira/browse/CALCITE-6482 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: kate >Priority: Minor > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6472) Add degree based trig functions to PostgreSQL function library
[ https://issues.apache.org/jira/browse/CALCITE-6472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6472: Labels: pull-request-available (was: ) > Add degree based trig functions to PostgreSQL function library > -- > > Key: CALCITE-6472 > URL: https://issues.apache.org/jira/browse/CALCITE-6472 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Norman Jordan >Assignee: Norman Jordan >Priority: Minor > Labels: pull-request-available > > PostgreSQL supports the following trigonometric functions that are degree > based. > * COSD > * SIND > * TAND > * ACOSD > * ASIND > * ATAND -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6474) Aggregate with constant key can get a RowCount greater than its MaxRowCount
[
https://issues.apache.org/jira/browse/CALCITE-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6474:
Labels: pull-request-available (was: )
> Aggregate with constant key can get a RowCount greater than its MaxRowCount
> ---
>
> Key: CALCITE-6474
> URL: https://issues.apache.org/jira/browse/CALCITE-6474
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> An Aggregate with constant key can get a RowCount greater than its
> MaxRowCount.
> The root cause is that this logic in RelMdMaxRowCount
> {code}
> // Aggregate with constant GROUP BY always returns 1 row
> if (rel.getGroupType() == Aggregate.Group.SIMPLE) {
> final RelOptPredicateList predicateList =
> mq.getPulledUpPredicates(rel.getInput());
> if (!RelOptPredicateList.isEmpty(predicateList)
> && allGroupKeysAreConstant(rel, predicateList)) {
> return 1D;
> }
> }
> {code}
> is not applied in RelMdRowCount.
> Therefore we can get an Aggregate whose MaxRowCount is 1, but its RowCount is
> X (> 1).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6473) HAVING clauses may not contain window functions
[
https://issues.apache.org/jira/browse/CALCITE-6473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6473:
Labels: pull-request-available (was: )
> HAVING clauses may not contain window functions
> ---
>
> Key: CALCITE-6473
> URL: https://issues.apache.org/jira/browse/CALCITE-6473
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Labels: pull-request-available
>
> according to the standard:
> {code}
> The shall not contain a without an
> intervening .
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6296) Support IS NULL in Arrow adapter
[
https://issues.apache.org/jira/browse/CALCITE-6296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6296:
Labels: pull-request-available (was: )
> Support IS NULL in Arrow adapter
>
>
> Key: CALCITE-6296
> URL: https://issues.apache.org/jira/browse/CALCITE-6296
> Project: Calcite
> Issue Type: Sub-task
> Components: arrow-adapter
>Reporter: hongyu guo
>Assignee: Tim Grein
>Priority: Major
> Labels: pull-request-available
>
> {code:sql}
> select "intField", "stringField"
> from arrowdata
> where "intField" is null
> {code}
> will throw an exception
> {code:java}
> java.lang.AssertionError: cannot translate IS NULL($0)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateMatch2(ArrowTranslator.java:131)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateAnd(ArrowTranslator.java:111)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateMatch(ArrowTranslator.java:68)
> at
> org.apache.calcite.adapter.arrow.ArrowFilter.(ArrowFilter.java:43)
> at
> org.apache.calcite.adapter.arrow.ArrowRules$ArrowFilterRule.convert(ArrowRules.java:97)
> at
> org.apache.calcite.adapter.arrow.ArrowRules$ArrowFilterRule.onMatch(ArrowRules.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6470) Run specific JMH benchmarks without modifying sources
[
https://issues.apache.org/jira/browse/CALCITE-6470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6470:
Labels: pull-request-available (was: )
> Run specific JMH benchmarks without modifying sources
> -
>
> Key: CALCITE-6470
> URL: https://issues.apache.org/jira/browse/CALCITE-6470
> Project: Calcite
> Issue Type: Improvement
> Components: build
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> Currently we can run *all* JMH benchmarks of the project using the "jmh"
> Gradle task.
> {code:java}
> ./gradlew :ubenchmark:jmh
> {code}
> In many cases, we don't want to run all benchmarks but only one (or few) and
> this is not possible without modifying the Gradle build files (see
> https://github.com/melix/jmh-gradle-plugin/issues/152).
> The goal of this ticket is to add a (project) property (i.e., jmh.includes)
> to select the desired benchmarks via a regular expression that can be passed
> in the command line.
> {code:java}
> ./gradlew :ubenchmark:jmh -Pjmh.includes=ParserBenchmark
> {code}
> For example, the command above would run only the ParserBenchmark.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6464) Type inference for DECIMAL division seems incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6464: Labels: pull-request-available (was: ) > Type inference for DECIMAL division seems incorrect > --- > > Key: CALCITE-6464 > URL: https://issues.apache.org/jira/browse/CALCITE-6464 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.37.0 >Reporter: Mihai Budiu >Assignee: Tim Grein >Priority: Minor > Labels: pull-request-available > > This bug surfaces if one uses a custom type system, e.g., where DECIMAL is > limited to (28, 10). > The problem is in RelDataTypeSystem.deriveDecimalDivideType. > The JavaDoc of this function gives the algorithm for deriving the division > result type. > According to these rules, if you divide two numbers of type DECIMAL(28, 10), > you should get a result with type DECIMAL(28, 10). > But the actual implementation infers a type of DECIMAL(28, 0), which seems > incorrect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6468) RelDecorrelator throws AssertionError if correlated variable is used as Aggregate group key
[
https://issues.apache.org/jira/browse/CALCITE-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6468:
Labels: pull-request-available (was: )
> RelDecorrelator throws AssertionError if correlated variable is used as
> Aggregate group key
> ---
>
> Key: CALCITE-6468
> URL: https://issues.apache.org/jira/browse/CALCITE-6468
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> The problem can be reproduced with this query (a "simplified" version of
> TPC-DS query1):
> {code:sql}
> WITH agg_sal AS
> (SELECT deptno, sum(sal) AS total FROM emp GROUP BY deptno)
> SELECT 1 FROM agg_sal s1
> WHERE s1.total > (SELECT avg(total) FROM agg_sal s2 WHERE s1.deptno =
> s2.deptno)
> {code}
> If we apply subquery program, FilterAggregateTransposeRule and then we call
> the RelDecorrelator, it will fail with:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:581)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:495)
> ...
> {noformat}
> The problem appears in this assert (RelDecorrelator.java:581):
> {code}
> assert newPos == newInputOutput.size();
> {code}
> The root cause seems to be that, a few lines before, when processing the
> correlating variables from {{corDefOutputs}} a certain value is inserted in
> {{mapNewInputToProjOutputs}}:
> {code}
> if (!frame.corDefOutputs.isEmpty()) {
> for (Map.Entry entry : frame.corDefOutputs.entrySet()) {
> RexInputRef.add2(projects, entry.getValue(), newInputOutput);
> corDefOutputs.put(entry.getKey(), newPos);
> mapNewInputToProjOutputs.put(entry.getValue(), newPos); // <-- HERE
> newPos++;
> }
> }
> {code}
> The problem is that this value was already in the map, as it had been
> inserted previously as part of the group key processing:
> {code}
> for (int i = 0; i < oldGroupKeyCount; i++) {
> final int idx = groupKeyIndices.get(i);
> ...
> // add mapping of group keys.
> outputMap.put(idx, newPos);
> int newInputPos = requireNonNull(frame.oldToNewOutputs.get(idx));
> RexInputRef.add2(projects, newInputPos, newInputOutput);
> mapNewInputToProjOutputs.put(newInputPos, newPos); // <-- HERE added firstly
> newPos++;
> }
> {code}
> Therefore, the unnecessary insertion into {{mapNewInputToProjOutputs}} and
> the subsequent increment of {{newPos}} when the {{CorDef}}s are processed
> leads to the mismatch.
> Notice how, right before the assertion, when processing the remaining fields,
> it is verified that the value is not already contained on the
> {{mapNewInputToProjOutputs}}:
> {code}
> // add the remaining fields
> final int newGroupKeyCount = newPos;
> for (int i = 0; i < newInputOutput.size(); i++) {
> if (!mapNewInputToProjOutputs.containsKey(i)) { // <-- HERE checked
> RexInputRef.add2(projects, i, newInputOutput);
> mapNewInputToProjOutputs.put(i, newPos);
> newPos++;
> }
> }
> {code}
> Thus, probably the solution would be to apply the same logic when the CorDef
> are processed:
> {code}
> if (!frame.corDefOutputs.isEmpty()) {
> for (Map.Entry entry : frame.corDefOutputs.entrySet()) {
> final Integer pos = mapNewInputToProjOutputs.get(entry.getValue()); //
> <-- HERE add map verification
> if (pos == null) {
> RexInputRef.add2(projects, entry.getValue(), newInputOutput);
> corDefOutputs.put(entry.getKey(), newPos);
> mapNewInputToProjOutputs.put(entry.getValue(), newPos);
> newPos++;
> } else {
> corDefOutputs.put(entry.getKey(), pos);
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6466) Sql Parsers instantiation is slow
[
https://issues.apache.org/jira/browse/CALCITE-6466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6466:
Labels: pull-request-available (was: )
> Sql Parsers instantiation is slow
> -
>
> Key: CALCITE-6466
> URL: https://issues.apache.org/jira/browse/CALCITE-6466
> Project: Calcite
> Issue Type: Improvement
>Reporter: Cyril de Catheu
>Priority: Minor
> Labels: pull-request-available
>
> *Summary:*
> Sql Parsers instantiation is slow because it instantiates a Throwable with a
> stacktrace.
> The speed of instantiation also depends on the call stack depth at the time
> of instantiation. The deeper in the call stack, the slower the instantiation.
> *Analysis:*
> This is an issue caused by JavaCC. The issue is fixed in newer version of
> JavaCC.
> Once JavaCC is upgraded to 7.0.13
> (https://issues.apache.org/jira/browse/CALCITE-5541), this benchmark can be
> re-run.
> See full discussion here:
> [https://lists.apache.org/thread/xw35sdy1w1k8lvn1q1lr7xb93bkj0lpq]
> {*}TODO{*}:
> Add a benchmark to measure the evolution of this issue.
> The benchmark can be re-run once
> https://issues.apache.org/jira/browse/CALCITE-5541 is done.
> Expected improvements are:
> - a minor speed improvement of ~10% for all parsers impacted by the issue
> - the instantiation of parsers should not depend on the call stack depth
> anymore
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-1012) Benchmark SQL parser
[ https://issues.apache.org/jira/browse/CALCITE-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-1012: Labels: pull-request-available (was: ) > Benchmark SQL parser > > > Key: CALCITE-1012 > URL: https://issues.apache.org/jira/browse/CALCITE-1012 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Priority: Major > Labels: pull-request-available > Attachments: allocations1.png, allocations2.png, allocations3.png, > allocations4.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6454) Implement array comparison operators
[
https://issues.apache.org/jira/browse/CALCITE-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6454:
Labels: pull-request-available (was: )
> Implement array comparison operators
>
>
> Key: CALCITE-6454
> URL: https://issues.apache.org/jira/browse/CALCITE-6454
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Norman Jordan
>Assignee: Norman Jordan
>Priority: Major
> Labels: pull-request-available
>
> The comparison operators <, <=, >, >=, =, <> are not implemented for arrays.
> Here is an example query:
>
> {code:java}
> SELECT array[2, 2] > array[1, 1]; {code}
> [This
> page|https://popsql.com/learn-sql/postgresql/how-to-compare-arrays-in-postgresql]
> describes how the comparisons work in PostgreSQL.
>
> Check if the comparison operators for arrays exist in other DB engines.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6462) VolcanoPlanner internal valid may throw exception when log trace is enabled
[
https://issues.apache.org/jira/browse/CALCITE-6462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6462:
Labels: pull-request-available (was: )
> VolcanoPlanner internal valid may throw exception when log trace is enabled
> ---
>
> Key: CALCITE-6462
> URL: https://issues.apache.org/jira/browse/CALCITE-6462
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> Unit test in JdbcAdapterTest:
> {code:java}
> @Test void testAioob_5() {
> CalciteAssert.model(JdbcTest.SCOTT_MODEL)
> .query("select *\n"
> + "from scott.emp e left join scott.dept d\n"
> + "on 'job' in (select job from scott.bonus b)")
> .runs();
> }{code}
> Exceptions:
> {code:java}
> RelSubset [rel#108:RelSubset#7.ENUMERABLE.[]] has wrong best cost {1254.5
> rows, 340.5 cpu, 0.0 io}. Correct cost is {1752.0 rows, 337.5 cpu, 0.0
> io}{code}
> The best RelNode and the bestCode is different.
> When log trace is enabled, Tte code will be run:
> {code:java}
> if (LOGGER.isDebugEnabled()) {
> assert isValid(Litmus.THROW);
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6460) SortRemoveConstantKeysRule fails with AssertionError due to mismatched collation on resulting Sort
[
https://issues.apache.org/jira/browse/CALCITE-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6460:
Labels: pull-request-available (was: )
> SortRemoveConstantKeysRule fails with AssertionError due to mismatched
> collation on resulting Sort
> --
>
> Key: CALCITE-6460
> URL: https://issues.apache.org/jira/browse/CALCITE-6460
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> When {{SortRemoveConstantKeysRule}} is applied, at the end of the process it
> creates the resulting Sort with the new collation (which has removed the
> constant keys from the original one):
> {code}
> final Sort result =
> sort.copy(sort.getTraitSet(), input,
> RelCollations.of(collationsList));
> {code}
> However, if there's a collation defined inside's the Sort's traitSet, this
> copy will fail, because there will be a mismatch between the (original)
> collation in the traitSet (which is unchanged at the moment of the copy) and
> the new collation that has been computed by the rule (removing constant keys):
> {noformat}
> traits=NONE.[1, 2 DESC], collation=[2 DESC]
> java.lang.AssertionError: traits=NONE.[1, 2 DESC], collation=[2 DESC]
> at org.apache.calcite.rel.core.Sort.(Sort.java:87)
> at
> org.apache.calcite.rel.logical.LogicalSort.(LogicalSort.java:48)
> at org.apache.calcite.rel.logical.LogicalSort.copy(LogicalSort.java:81)
> at org.apache.calcite.rel.core.Sort.copy(Sort.java:150)
> at
> org.apache.calcite.rel.rules.SortRemoveConstantKeysRule.onMatch(SortRemoveConstantKeysRule.java:85)
> ...
> {noformat}
> This problem only happens if the traitSet includes
> {{RelCollationTraitDef.INSTANCE}}, so it can be unnoticed in many cases.
> However, we can reproduce it by adjusting
> {{RelOptRulesTest#testSortRemovalOneKeyConstant}}:
> {code}
> sql(sql)
> .withVolcanoPlanner(false, p -> {
> p.addRelTraitDef(RelCollationTraitDef.INSTANCE);
> RelOptUtil.registerDefaultRules(p, false, false);
> })
> .withRule(CoreRules.SORT_REMOVE_CONSTANT_KEYS)
> .check();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6448) FilterReduceExpressionsRule returns empty RelNode for RexLiterals
[
https://issues.apache.org/jira/browse/CALCITE-6448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6448:
Labels: pull-request-available (was: )
> FilterReduceExpressionsRule returns empty RelNode for RexLiterals
> -
>
> Key: CALCITE-6448
> URL: https://issues.apache.org/jira/browse/CALCITE-6448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Soumyakanti Das
>Assignee: Soumyakanti Das
>Priority: Major
> Labels: pull-request-available
>
> In Hive, for simple queries with {{WHERE 'foo'}} we get an empty result,
> where as for simple queries with {{WHERE t.stringColumn}} we get non-empty
> result.
> Currently in {{FilterReduceExpressionsRule}}, all {{RexLiteral}}s are
> converted to empty values by
> {code:java}
> else if (newConditionExp instanceof RexLiteral
> || RexUtil.isNullLiteral(newConditionExp, true)) {
> call.transformTo(createEmptyRelOrEquivalent(call, filter));
> {code}
> This might be not inline with {{RexLiteral#isAlwaysFalse}}, and it might be
> safer to leave the literal as it is.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6413) SqlValidator does not invoke TypeCoercionImpl::binaryComparisonCoercion for both NATURAL and USING join conditions
[
https://issues.apache.org/jira/browse/CALCITE-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6413:
Labels: pull-request-available (was: )
> SqlValidator does not invoke TypeCoercionImpl::binaryComparisonCoercion for
> both NATURAL and USING join conditions
> ---
>
> Key: CALCITE-6413
> URL: https://issues.apache.org/jira/browse/CALCITE-6413
> Project: Calcite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: pull-request-available
>
> This can be observed by adding these test cases to `SqlToRelConverterTest`:
> 1. Join condition ON expression
> {code:java}
> @Test void test1() {
> final String sql = "select * from emp JOIN (VALUES ('XXX')) t(deptno) ON
> emp.deptno = t.deptno";
> sql(sql).ok();
> }
> {code}
> 2. Common columns (USING/NATURAL) (since they both share the same code path
> for building join condition)
> {code:java}
> @Test void test2() {
> final String sql = "select * from emp JOIN (VALUES ('XXX')) t(deptno)
> USING (deptno)";
> sql(sql).ok();
> }
> {code}
> When test 1 runs, the SqlValidator calls
> TypeCoercionImpl::binaryComparisonCoercion
> When test 2 runs, the SqlValidator does not call
> TypeCoercionImpl::binaryComparisonCoercion.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6435) SqlToRel conversion of IN expressions may lead to incorrect simplifications
[
https://issues.apache.org/jira/browse/CALCITE-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6435:
Labels: pull-request-available (was: )
> SqlToRel conversion of IN expressions may lead to incorrect simplifications
> ---
>
> Key: CALCITE-6435
> URL: https://issues.apache.org/jira/browse/CALCITE-6435
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Labels: pull-request-available
>
> the query must have the following features:
> * not all columns are selected
> ** to enable {{RelFieldTrimmer}} to start a cycle
> * two equivalent eq filters
> ** one in {{IN}} form ({{ename in ( 'Sebastian' )}})
> ** a regular {{=}} ({{ename = 'Sebastian'}})
> * an unrelated filter like {{deptno < 100}}
> the optimizer should more-or-less start with the `RelFieldTrimmer`
> the issue happens like:
> * at parse time both literals are parsed as {{CHAR( n )}}
> * the number of values in the `IN` is below `inSubqueryThreshold` - so it
> gets converted to a set of `=` filters
> ** expression is converted to OR form
> ** during conversion
> [SqlToRelConverter#ensureSqlType|https://github.com/apache/calcite/blob/fb15511e76c660cbd440578421645ebe63941bf7/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L1777-L1779]
> is called
> *** which skips the conversion for *CHAR / VARCHAR*
> * the *=* filter goes thru the "regular" rex conversion - which involves
> calling *rexBuilder#ensureType*
> * the filter condition contains *ename = 'Sebastian'* twice; however the
> types differ
> * *RelFieldTrimmer* starts a change cycle ; which induces the simplification
> of the filter condition
> * *RexSimplify* is executed with predicate elimination disabled (this will
> be important)
> * simplification compares the two literals with
> [equals|https://github.com/apache/calcite/blob/fb15511e76c660cbd440578421645ebe63941bf7/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1685]
> and returns `false`
> workarounds:
> * disable the conversion by setting *inSubqueryThreshold=1*
> * run a rule which executes `RexSimplify` with predicate elimination enabled
> earlier than the trimmer (ex: *ReduceExpressionsRule*)
> ** I think this bug remained hidden because this might happen easily
> testcase for `RelOptRulesTest`
> {code:java}
> @Test void testIncorrectInType() {
> final String sql = "select ename from emp "
> + " where ename in ( 'Sebastian' ) and ename = 'Sebastian' and
> deptno < 100";
> sql(sql)
> .withTrim(true)
> .withRule()
> .checkUnchanged();
> }
> {code}
> results in plan
> {code:java}
> LogicalProject(ENAME=[$0])
> LogicalValues(tuples=[[]])
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6450) Postgres CONCAT_WS function throws exception when parameter type is (, )
[
https://issues.apache.org/jira/browse/CALCITE-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6450:
Labels: pull-request-available (was: )
> Postgres CONCAT_WS function throws exception when parameter type is
> (, )
>
>
> Key: CALCITE-6450
> URL: https://issues.apache.org/jira/browse/CALCITE-6450
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2024-06-29-14-57-56-513.png
>
>
> The SQL can run success in Postgres:
> {code:java}
> select concat_ws(',',ARRAY[1, 1, 1, 1]); {code}
> But in Calcite, It will throw exception:
> {code:java}
> @Test void testConcatFunction() {
> final String sql = "select concat_ws(',',ARRAY[1, 1, 1, 1])
> as c";
> fixture()
> .withFactory(c ->
> c.withOperatorTable(t ->
> SqlValidatorTest.operatorTableFor(SqlLibrary.POSTGRESQL)))
> .withCatalogReader(MockCatalogReaderExtended::create)
> .withSql(sql)
> .ok();
> }{code}
> {code:java}
> From line 1, column 8 to line 1, column 55: Cannot apply 'CONCAT_WS' to
> arguments of type 'CONCAT_WS(, )'. Supported form(s):
> 'CONCAT_WS()'{code}
> This issue find in comment
> [CALCITE-6446|https://github.com/apache/calcite/pull/3831] .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6451) Improve Nullability Derivation for Intersect and Minus
[
https://issues.apache.org/jira/browse/CALCITE-6451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6451:
Labels: pull-request-available (was: )
> Improve Nullability Derivation for Intersect and Minus
> --
>
> Key: CALCITE-6451
> URL: https://issues.apache.org/jira/browse/CALCITE-6451
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Victor Barua
>Assignee: Victor Barua
>Priority: Minor
> Labels: pull-request-available
>
> SetOp overrides `deriveRowType()` and computes the output row type to be the
> least restrictive across all inputs
> [here|https://github.com/apache/calcite/blob/8ab0b03326730aa2cc6b476b2cbd8f99799bdacb/core/src/main/java/org/apache/calcite/rel/core/SetOp.java#L116-L127].
>
> So for example given
> {code:java}
> Input 1: (I64, I64, I64?, I64?)
> Input 2: (I64, I64?, I64, I64?) {code}
> where ? denotes nullable, the least restrictive output computes:
> {code:java}
> Output: (I64, I64?, I64?, I64?) {code}
> For UNION operations, these nullabilities are accurate.
> However for MINUS and INTERSECT there is room for improvement.
> *MINUS* only returns rows from the first input, as such its output
> nullability should always match that of its first input:
> {code:java}
> Output: (I64, I64, I64?, I64?) {code}
> *INTERSECT* only returns rows that match across all inputs. If a column is
> not nullable in any of the inputs, then it is not nullable in the output
> because no rows can be emitted in which that column is null:
> {code:java}
> Output: (I64, I64, I64, I64?) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6457) The array_contains function return false when arrayComponentType and op1 type are different
[ https://issues.apache.org/jira/browse/CALCITE-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6457: Labels: pull-request-available (was: ) > The array_contains function return false when arrayComponentType and op1 > type are different > > > Key: CALCITE-6457 > URL: https://issues.apache.org/jira/browse/CALCITE-6457 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.37.0 >Reporter: Caican Cai >Priority: Major > Labels: pull-request-available > > In Spark, array_contains(array(1.0, 2), 1) returns true because Spark > converts array and op1 types to the biggesttype. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6401) JDBC adapter cannot push down joins with complex JOIN condition
[
https://issues.apache.org/jira/browse/CALCITE-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6401:
Labels: pull-request-available (was: )
> JDBC adapter cannot push down joins with complex JOIN condition
> ---
>
> Key: CALCITE-6401
> URL: https://issues.apache.org/jira/browse/CALCITE-6401
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.36.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> JDBC adapter (in JdbcJoinRule) cannot push down joins with conditions which
> include operations not listed in {{JdbcJoinRule::canJoinOnCondition}}.
> See also CALCITE-4907
> For example the following statement is executed using an
> {{EnumerableNestedLoopJoin}}
> {code:SQL}
> SELECT
> *
> FROM
>A
> JOIN (
> SELECT
> D."userId",
> MAX(D."id") as "id"
> FROM
>D
> GROUP BY
> D."userId"
> ) B ON (
> A."id" = B."id" AND A."userId" IS NOT NULL
> )
> OR (
> A."userId" = B."userId" AND A."id" IS NOT NULL
> )
> {code}
> Adding the cases {{IS_NULL}} and {{IS_NOT_NULL}} to
> {{JdbcJoinRule::canJoinOnCondition}} fixes the problem for this statement.
> But I was not able to find out which cases are also missing here. E.g. a join
> condition which compares a RexInputRef with a RexLiteral also fails.
> Where could I find the associated code in {{JdbcJoin::implement}} that makes
> it impossible to create an appropriate SQL statement if all operations were
> allowed?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6436) JDBC adapter generates SQL missing parentheses when comparing 3 values with the same precedence like (a=b)=c
[
https://issues.apache.org/jira/browse/CALCITE-6436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6436:
Labels: pull-request-available (was: )
> JDBC adapter generates SQL missing parentheses when comparing 3 values with
> the same precedence like (a=b)=c
>
>
> Key: CALCITE-6436
> URL: https://issues.apache.org/jira/browse/CALCITE-6436
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ulrich Kramer
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> Running the following unit test in {{JdbcAdapterTest}} fails with
> {code:java}
> @Test void testOperatorInWhere() {
> CalciteAssert.model(FoodmartSchema.FOODMART_MODEL)
> .query("select * from \"sales_fact_1997\" "
> + "where (\"product_id\" = 1) = ?")
> .consumesPreparedStatement(p -> p.setBoolean(1, true))
> .runs();
> }
> {code}
> {noformat}
> Caused by: java.sql.SQLSyntaxErrorException: unexpected token: = : line: 3 in
> statement [SELECT *
> FROM "foodmart"."sales_fact_1997"
> WHERE "product_id" = 1 = ?
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6453) Simplify casts which are result of constant reduction
[
https://issues.apache.org/jira/browse/CALCITE-6453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6453:
Labels: pull-request-available (was: )
> Simplify casts which are result of constant reduction
> -
>
> Key: CALCITE-6453
> URL: https://issues.apache.org/jira/browse/CALCITE-6453
> Project: Calcite
> Issue Type: Improvement
>Reporter: Krisztian Kasa
>Assignee: Krisztian Kasa
>Priority: Major
> Labels: pull-request-available
>
> RexSimplify transforms nullable cast expressions with a non-nullable literal
> operand which type is different from the cast type to another cast expression
> with a literal operand with the same type as the cast.
> If simplify is called again using the result cast expression of the first
> simplification we get a literal only as a result.
> Example:
> Initial expression
> {code:java}
> CAST(_UTF-16LE'2020-10-30':VARCHAR(2147483647) CHARACTER SET "UTF-16LE"):DATE
> {code}
> where the operand is non-nullable varchar and the result of the cast is
> nullable date.
> After the first simplify call we get
> {code:java}
> CAST(2020-10-30:DATE):DATE
> {code}
> where the operand type is non-nullable date and the cast type is nullable
> date.
> https://github.com/apache/calcite/blob/8ab0b03326730aa2cc6b476b2cbd8f99799bdacb/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L2269-L2276
> After the second simplify call we get
> {code:java}
> 2020-10-30:DATE
> {code}
> where the literal type is non-nullable date
> https://github.com/apache/calcite/blob/8ab0b03326730aa2cc6b476b2cbd8f99799bdacb/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L2195-L2196
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-4921) Nested NATURAL JOINs or JOINs with USING can't find common column
[
https://issues.apache.org/jira/browse/CALCITE-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4921:
Labels: pull-request-available (was: )
> Nested NATURAL JOINs or JOINs with USING can't find common column
> -
>
> Key: CALCITE-4921
> URL: https://issues.apache.org/jira/browse/CALCITE-4921
> Project: Calcite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: pull-request-available
>
> {{SqlValidatorUtil#deriveNaturalJoinColumnList}} can't correctly derive
> common columns for JOIN if the left hand of it is another NATURAL JOIN or
> JOIN with USING. For example:
> {noformat}
> SELECT * FROM (values (1, 1)) as t1(a, b)
> NATURAL JOIN (values (1, 1)) as t2(a, c)
> NATURAL JOIN (values (1, 1)) as t3(a, d){noformat}
> Builds incorrect plan:
> {noformat}
> LogicalProject(A=[$0], B=[$1], C=[$3], A1=[$4], D=[$5])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalJoin(condition=[=($0, $2)], joinType=[inner])
> LogicalValues(tuples=[[{ 1, 1 }]])
> LogicalValues(tuples=[[{ 1, 1 }]])
> LogicalValues(tuples=[[{ 1, 1 }]]){noformat}
> Queries with USING also have problems:
> {noformat}
> SELECT * FROM (values (1, 1)) as t1(a, b)
> JOIN (values (1, 1)) as t2(a, c) USING (a)
> JOIN (values (1, 1)) as t3(a, d) USING (a){noformat}
> Fails with:
> {noformat}
> Column name 'A' in USING clause is not unique on one side of join{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6312) Add LOG function (enabled in PostgreSQL library)
[ https://issues.apache.org/jira/browse/CALCITE-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6312: Labels: pull-request-available (was: ) > Add LOG function (enabled in PostgreSQL library) > > > Key: CALCITE-6312 > URL: https://issues.apache.org/jira/browse/CALCITE-6312 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Assignee: Caican Cai >Priority: Minor > Labels: pull-request-available > > * We have the BigQuery implementation which has a 1-arg overload that uses > base e (ln), and a 2-arg overload which is LOG(value, base) > * PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the > order reversed – LOG(base, value) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6449) Enable PostgreSQL implementations of to_date/to_timestamp
[
https://issues.apache.org/jira/browse/CALCITE-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6449:
Labels: pull-request-available (was: )
> Enable PostgreSQL implementations of to_date/to_timestamp
> -
>
> Key: CALCITE-6449
> URL: https://issues.apache.org/jira/browse/CALCITE-6449
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: Norman Jordan
>Assignee: Norman Jordan
>Priority: Minor
> Labels: pull-request-available
>
> Update the PostgreSQL function library to use PostgreSQL specific
> implementations for *TO_DATE* and {*}TO_TIMESTAMP{*}. These implementations
> should fully support the date/time formatting patterns that PostgreSQL
> supports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6447) extract common expressions for disjunctions in Join
[
https://issues.apache.org/jira/browse/CALCITE-6447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6447:
Labels: pull-request-available (was: )
> extract common expressions for disjunctions in Join
> ---
>
> Key: CALCITE-6447
> URL: https://issues.apache.org/jira/browse/CALCITE-6447
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.37.0
>Reporter: ruanhui
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> For SQL:
> {code:java}
> select *
> from tbl_a
> join tbl_b on tbl_a.id = tbl_b.id
> where (tbl_a.x > 100 and tbl_b.y < 10)
>or (tbl_a.x > 100 and tbl_b.z > 20){code}
> we can rewrite it to
> {code:java}
> select *
> from tbl_a
> join tbl_b on tbl_a.id = tbl_b.id
> where tbl_a.x > 100
> and (tbl_b.y < 10 or tbl_b.z > 20){code}
> And in this way *tbl_a.x > 100* can be pushed down and it is likely that this
> will help reduce the amount of data involved in the join.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6444) Add an Amazon Redshift SqlLibrary
[ https://issues.apache.org/jira/browse/CALCITE-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6444: Labels: pull-request-available (was: ) > Add an Amazon Redshift SqlLibrary > -- > > Key: CALCITE-6444 > URL: https://issues.apache.org/jira/browse/CALCITE-6444 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.34.0 >Reporter: Norman Jordan >Assignee: Norman Jordan >Priority: Major > Labels: pull-request-available > > The Babel tests assume that RedShift is a union of the Oracle and PostgreSQL > libraries. This is not accurate. There are functions such as *INCR* that are > supported by Oracle and not by RedShift. Problems will also occur when Oracle > and Postgres both support a function of the same name that needs different > implementations. > [https://github.com/apache/calcite/blob/main/babel/src/test/java/org/apache/calcite/test/BabelQuidemTest.java#L110] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6446) Add CONCAT_WS function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6446: Labels: pull-request-available (was: ) > Add CONCAT_WS function (enabled in Spark library) > - > > Key: CALCITE-6446 > URL: https://issues.apache.org/jira/browse/CALCITE-6446 > Project: Calcite > Issue Type: Improvement >Reporter: EveyWu >Priority: Minor > Labels: pull-request-available > > Add Spark functions that have been implemented but have different > OperandTypes/Returns. > Add Function > [CONCAT_WS|https://spark.apache.org/docs/latest/api/sql/index.html#concat_ws] > The concat argument type supports not only the string type but also the array > type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6445) Add REVERSE function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6445: Labels: pull-request-available (was: ) > Add REVERSE function (enabled in Spark library) > --- > > Key: CALCITE-6445 > URL: https://issues.apache.org/jira/browse/CALCITE-6445 > Project: Calcite > Issue Type: Improvement >Reporter: EveyWu >Priority: Minor > Labels: pull-request-available > > Add Spark functions that have been implemented but have different > OperandTypes/Returns. > Add Function [REVERSE|https://spark.apache.org/docs/latest/api/sql/#reverse] > The parameter type supports not only the string type but also the array type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-3094) Code of method grows beyond 64 KB when joining two tables with many fields
[
https://issues.apache.org/jira/browse/CALCITE-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3094:
Labels: pull-request-available (was: )
> Code of method grows beyond 64 KB when joining two tables with many fields
> --
>
> Key: CALCITE-3094
> URL: https://issues.apache.org/jira/browse/CALCITE-3094
> Project: Calcite
> Issue Type: Bug
> Components: core, jdbc-adapter
>Affects Versions: 1.19.0
>Reporter: Pablo
>Assignee: James Duong
>Priority: Critical
> Labels: pull-request-available
> Attachments: CTE-3094.zip
>
>
> I am running simple queries like these:
> {{SELECT * FROM t0 INNER JOIN t1 ON t0.`f00` = t1.`f03`"}}
>
> They are running ok, but, when t1 and t0 have about 3290 fields, I get this
> error.
> Is there anything I can do? I can't do joins with this amount of fields?
>
> Thank you in advance
>
> {noformat}
> Caused by: java.lang.RuntimeException: Error while compiling generated Java
> code:
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.rel.RelNode v2stashed =
> (org.apache.calcite.rel.RelNode) root.get("v2stashed");
> final org.apache.calcite.rel.RelNode v1stashed =
> (org.apache.calcite.rel.RelNode) root.get("v1stashed");
> final org.apache.calcite.interpreter.Interpreter interpreter = new
> org.apache.calcite.interpreter.Interpreter(
> root,
> v1stashed);
> final org.apache.calcite.interpreter.Interpreter interpreter0 = new
> org.apache.calcite.interpreter.Interpreter(
> root,
> v2stashed);
> return interpreter.join(interpreter0, new
> org.apache.calcite.linq4j.function.Function1() {
> public Byte apply(Object[] v1) {
> return (Byte) v1[0];
> }
> public Object apply(Object v1) {
> return apply(
> (Object[]) v1);
> }
> }
> , new org.apache.calcite.linq4j.function.Function1() {
> public Byte apply(Object[] v1) {
> return (Byte) v1[3];
> }
> public Object apply(Object v1) {
> return apply(
> (Object[]) v1);
> }
> }
> , new org.apache.calcite.linq4j.function.Function2() {
> public Object[] apply(Object[] left, Object[] right) {
> return new Object[] {
> left[0],
> left[1],
> left[2],
> [...elided ...]
> left[3298],
> left[3299],
> right[0],
> right[1],
> [...elided...]]
> right[3295],
> right[3296],
> right[3297],
> right[3298],
> right[3299]};
> }
> public Object[] apply(Object left, Object right) {
> return apply(
> (Object[]) left,
> (Object[]) right);
> }
> }
> , null, false, false);
> }
> public Class getElementType() {
> return java.lang.Object[].class;
> }
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:128)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:332)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:767)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:631)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:601)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:211)
> ... 80 more
> Caused by: org.codehaus.janino.InternalCompilerException: Compiling "Baz":
> Code of method
> "apply([Ljava/lang/Object;[Ljava/lang/Object;)[Ljava/lang/Object;" of class
> "Baz$3" grows beyond 64 KB
> at org.codehaus.janino.UnitCompiler.compileUnit(UnitCompiler.java:382)
> at org.codehaus.janino.SimpleCompiler.cook(SimpleCompiler.java:237)
> at
> org.codehaus.janino.SimpleCompiler.compileToClassLoader(SimpleCompiler.java:465)
> at
> org.codehaus.janino.ClassBodyEvaluator.compileToClass(ClassBodyEvaluator.java:313)
> at org.codehaus.janino.ClassBodyEvaluator.cook(ClassBodyEvaluator.java:235)
> at org.codehaus.janino.SimpleCompiler.cook(SimpleCompiler.java:207)
> at org.codehaus.commons.compiler.Cookable.cook(Cookable.java:50)
> at
> org.codehaus.janino.ClassBodyEvaluator.createInstance(ClassBodyEvaluator.java:347)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.getBindable(EnumerableInterpretable.java:162)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:125)
> ... 88 more
> Caused by: org.codehaus.janino.InternalCompilerException: Code of method
> "apply([Ljava/lang/Object;[Ljava/lang/Object;)[Ljava/lang/Object;" of class
> "Baz$3" grows
[jira] [Updated] (CALCITE-6440) Add optimization to returns empty when The Order By parameter in the Sort operator is empty
[
https://issues.apache.org/jira/browse/CALCITE-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6440:
Labels: pull-request-available (was: )
> Add optimization to returns empty when The Order By parameter in the Sort
> operator is empty
> ---
>
> Key: CALCITE-6440
> URL: https://issues.apache.org/jira/browse/CALCITE-6440
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.37.0
>Reporter: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> For the following SQL:
> {code:java}
> select * from task order by null; {code}
> We could rewrite it to:
> {code:java}
> select * from task;{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6438) Add optimization to returns empty when the filter operator is a false instance
[
https://issues.apache.org/jira/browse/CALCITE-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6438:
Labels: pull-request-available (was: )
> Add optimization to returns empty when the filter operator is a false instance
> --
>
> Key: CALCITE-6438
> URL: https://issues.apache.org/jira/browse/CALCITE-6438
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.37.0
>Reporter: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> {code:java}
> select * from emp where false{code}
> The current logical plan in calcite is
> {code:java}
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalFilter(condition=[false])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]) {code}
> It can be optimized to
> {code:java}
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalValues(tuples=[[]]) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6437) For druid sql JSON_OBJECT() function results in RUNTIME_FAILURE when querying INFORMATION_SCHEMA.COLUMNS
[
https://issues.apache.org/jira/browse/CALCITE-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6437:
Labels: pull-request-available (was: )
> For druid sql JSON_OBJECT() function results in RUNTIME_FAILURE when querying
> INFORMATION_SCHEMA.COLUMNS
>
>
> Key: CALCITE-6437
> URL: https://issues.apache.org/jira/browse/CALCITE-6437
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: AlbericByte
>Priority: Critical
> Labels: pull-request-available
>
> there is but for druid sql :
> [https://github.com/apache/druid/issues/16356]
> h3. Description
> Running the following query
> {code:java}
> select JSON_OBJECT('name': COLUMN_NAME, 'type': DATA_TYPE) from
> INFORMATION_SCHEMA.COLUMNS{code}
> {{ }}
>
> produces
> {{}}
> {code:java}
> Error: RUNTIME_FAILURE (OPERATOR) cannot translate call json_object($t17,
> $t18, $t3, $t19, $t7) java.lang.RuntimeException {code}
>
> Note that the error message quotes the json_object call to receive five
> parameters, but maybe that's an unrelated internal detail.
> For comparison, the following works (but is useless):
> {code:java}
> select JSON_OBJECT('name': 'foo', 'type': 'VARCHAR'){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6434) Specify identifier quoting for HiveSqlDialect and SparkSqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6434:
Labels: pull-request-available (was: )
> Specify identifier quoting for HiveSqlDialect and SparkSqlDialect
> -
>
> Key: CALCITE-6434
> URL: https://issues.apache.org/jira/browse/CALCITE-6434
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> The SQL:
> {code:java}
> SELECT product.product_class_id C
> FROM foodmart.product
> LEFT JOIN (SELECT CASE COUNT(*) WHEN 0 THEN NULL WHEN 1 THEN
> MIN(product_class_id) ELSE (SELECT NULL
> UNION ALL
> SELECT NULL) END $f0
> FROM foodmart.product) t0 ON TRUE
> WHERE product.net_weight > t0.$f0{code}
> Generate by SINGLE_VALUE agg function.
> This SQL will parse failed in Spark Unless we add the identifier quoting like
> `t0`.`$f0`
> I will add identifier Quote String for Spark and Hive, Here is the document:
> * [https://spark.apache.org/docs/latest/sql-ref-identifier.html]
> *
> [https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties#ConfigurationProperties-hive.support.quoted.identifiers]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6432) Infinite loop for JoinPushTransitivePredicatesRule when there are multiple project expressions reference the same input field
[
https://issues.apache.org/jira/browse/CALCITE-6432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6432:
Labels: pull-request-available (was: )
> Infinite loop for JoinPushTransitivePredicatesRule when there are multiple
> project expressions reference the same input field
> -
>
> Key: CALCITE-6432
> URL: https://issues.apache.org/jira/browse/CALCITE-6432
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: asdfgh19
>Assignee: asdfgh19
>Priority: Minor
> Labels: pull-request-available
> Attachments: 1.png, 2.png
>
>
> Below is a newly created test case that is stuck in an infinite loop.
> {code:java}
> @Test void testProjectPredicatePull() {
> final String sql = "select e.ename, d.dname\n"
> + "from (select ename, deptno from emp where deptno = 10) e\n"
> + "join (select name dname, deptno, * from dept) d\n"
> + "on e.deptno = d.deptno";
> final HepProgram program = new HepProgramBuilder()
> .addRuleCollection(
> ImmutableList.of(CoreRules.FILTER_PROJECT_TRANSPOSE,
> CoreRules.JOIN_PUSH_TRANSITIVE_PREDICATES))
> .build();
> sql(sql).withProgram(program).check();
> } {code}
> !1.png|width=563,height=192!
> From the figure above, we can see the process of this infinite loop:
> # JOIN_PUSH_TRANSITIVE_PREDICATES infers DEPTNO = 10 from the left side of
> the Join
> # JOIN_PUSH_TRANSITIVE_PREDICATES creates a new Filter DEPTNO = 10 on the
> right side of the Join
> # FILTER_PROJECT_TRANSPOSE pushes this newly created Filter past the Project
> # JOIN_PUSH_TRANSITIVE_PREDICATES infers DEPTNO = 10 from the left side of
> the Join and infers {color:#FF}DEPTNO0 = 10{color} from the right side of
> the Join，Note that it is DEPTNO0, not DEPTNO
> # So, JOIN_PUSH_TRANSITIVE_PREDICATES creates a new Filter DEPTNO = 10 and
> put it to the right side of the Join again. And then the process keeps
> repeating.
> The reason is that when RelMdPredicates infers predicates for a project,
> and the project has multiple expressions referencing the same input field,
> for example, DEPT=$0 DEPT0=$0, and the input predicate is $0=10, the inferred
> result is DEPT0=10, which means that the predicates related to other
> expressions with the same input field (DEPT=10) are lost, leaving only the
> last one.
>
> Below is the test case from RelOptRulesTest and its planAfter.
> {code:java}
> @Test void testJoinPushTransitivePredicatesRule2() {
> final String sql = "select n1.SAL\n"
> + "from EMPNULLABLES_20 n1\n"
> + "where n1.SAL IN (\n"
> + " select n2.SAL\n"
> + " from EMPNULLABLES_20 n2\n"
> + " where n1.SAL = n2.SAL or n1.SAL = 4)";
> sql(sql).withDecorrelate(true)
> .withExpand(true)
> .withRule(CoreRules.FILTER_INTO_JOIN,
> CoreRules.JOIN_CONDITION_PUSH,
> CoreRules.JOIN_PUSH_TRANSITIVE_PREDICATES)
> .check();
> }{code}
> !2.png|width=563,height=175!
> In the case where the left side of the Join already has an identical
> predicate (>($5, 1000)), JOIN_PUSH_TRANSITIVE_PREDICATES infers a new
> predicate (LogicalFilter(condition=[>($5, 1000)])) from the right side of the
> Join and puts it on the left side of the Join. This is because the Project on
> the left side of the Join has SAL=[$5], SAL0=[$5], and
> JOIN_PUSH_TRANSITIVE_PREDICATES fails to find this predicate, so it creates a
> new one.
> If we add a new rule CoreRules.FILTER_PROJECT_TRANSPOSE to this test case
> and modify it slightly, it will also fall into an infinite loop.
> {code:java}
> @Test void testJoinPushTransitivePredicatesRule2() {
> final String sql = "select n1.SAL\n"
> + "from EMPNULLABLES_20 n1\n"
> + "where n1.SAL IN (\n"
> + " select n2.SAL\n"
> + " from EMPNULLABLES_20 n2\n"
> + " where n1.SAL = n2.SAL or n1.SAL = 4)";
> final HepProgram program = new HepProgramBuilder()
> .addRuleCollection(
> ImmutableList.of(CoreRules.FILTER_INTO_JOIN,
> CoreRules.FILTER_PROJECT_TRANSPOSE,
> CoreRules.JOIN_CONDITION_PUSH,
> CoreRules.JOIN_PUSH_TRANSITIVE_PREDICATES))
> .build();
> sql(sql).withDecorrelate(true)
> .withExpand(true)
> .withProgram(program)
> .check();
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6431) Implement the SINGLE_VALUE aggregation in HiveSqlDialect And SparkSQLDialect
[ https://issues.apache.org/jira/browse/CALCITE-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6431: Labels: pull-request-available (was: ) > Implement the SINGLE_VALUE aggregation in HiveSqlDialect And SparkSQLDialect > > > Key: CALCITE-6431 > URL: https://issues.apache.org/jira/browse/CALCITE-6431 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.37.0 >Reporter: xiong duan >Assignee: xiong duan >Priority: Major > Labels: pull-request-available > Fix For: 1.38.0 > > > When we use the SQL including the scalar query, converting this SQL Rel to > HiveSQL will include the SINGLE_VALUE aggregation function(HiveSQL can't > handle it) in the dialect SQL. > In this PR, I will add identifier Quote String for Spark and Hive, Here is > the document: > * [https://spark.apache.org/docs/latest/sql-ref-identifier.html] > * > [https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties#ConfigurationProperties-hive.support.quoted.identifiers] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6430) SINGLE_VALUE rewrite to wrong sql when the sub-query return one NOT-NULL value and NULL value in PostgreSQL、MySQL、HSQL dialect
[
https://issues.apache.org/jira/browse/CALCITE-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6430:
Labels: pull-request-available (was: )
> SINGLE_VALUE rewrite to wrong sql when the sub-query return one NOT-NULL
> value and NULL value in PostgreSQL、MySQL、HSQL dialect
> --
>
> Key: CALCITE-6430
> URL: https://issues.apache.org/jira/browse/CALCITE-6430
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> Calcite rewrite the SINGLE_VALUE to different sql :
> For example in HSQL:
> {code:java}
> CASE COUNT(*)
> WHEN 0 THEN NULL
> WHEN 1 THEN MIN()
> ELSE (VALUES 1 UNION ALL VALUES 1)
> END{code}
> This is right. But Calcite will generate：
> {code:java}
> CASE COUNT(result)
> WHEN 0 THEN NULL
> WHEN 1 THEN MIN()
> ELSE (VALUES 1 UNION ALL VALUES 1)
> END{code}
> This sql will return wrong result.
> For Example:
> tableA:
> ||c1||c2||
> |4|1|
> |NULL|NULL|
> |NULL|NULL|
> |NULL|NULL|
> TheSQL:
> {code:java}
> select *
> from tableA
> where c1 > (select c2 from tableA);{code}
> will throw : [21000][1242] Subquery returns more than 1 row
> But SQL:
> {code:java}
> select *
> from tableA left join (select case count(c2)
> when 0 then null
> when 1 then min(c2)
> else (select cast(null as integer) union all select cast(null as integer))
> end as alias
> from tableA) as t1 on true
> where tableA.c1 > t1.alias;{code}
> will return one row value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6429) Arrow adapter should default to the Enumerable convention for unsupported filters
[
https://issues.apache.org/jira/browse/CALCITE-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6429:
Labels: pull-request-available (was: )
> Arrow adapter should default to the Enumerable convention for unsupported
> filters
> -
>
> Key: CALCITE-6429
> URL: https://issues.apache.org/jira/browse/CALCITE-6429
> Project: Calcite
> Issue Type: Sub-task
> Components: arrow-adapter
>Affects Versions: 1.37.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> Currently, the adapter fails with different errors when one of the known
> unsupported features is used, while it might simply catch the
> "UnsupportedOperationException" and bail out, thus allowing to generate a
> plan where the unsupported operation is implemented in the Enumerable
> convention.
>
> For instance, currently several tests are disabled for this reason, like
> [testArrowProjectFieldsWithDisjunctiveFilter|https://github.com/apache/calcite/blob/be9b860ebf3143dcbdbd0ee1777e604f0ace7b3c/arrow/src/test/java/org/apache/calcite/adapter/arrow/ArrowAdapterTest.java#L242],
> because it would fail as follows:
> {code:java}
> Error while executing SQL "select "intField", "stringField"
> from arrowdata
> where "intField"=12 or "stringField"='12'": Error while applying rule
> ArrowFilterRule, args
> [rel#31:LogicalFilter.NONE.[](input=RelSubset#15,condition=OR(=($0, 12),
> =($1, '12'))), rel#1:ArrowTableScan.ARROW.[](table=[ARROW,
> ARROWDATA],fields=[0, 1, 2, 3])]
> java.sql.SQLException: Error while executing SQL "select "intField",
> "stringField"
> from arrowdata
> where "intField"=12 or "stringField"='12'": Error while applying rule
> ArrowFilterRule, args
> [rel#31:LogicalFilter.NONE.[](input=RelSubset#15,condition=OR(=($0, 12),
> =($1, '12'))), rel#1:ArrowTableScan.ARROW.[](table=[ARROW,
> ARROWDATA],fields=[0, 1, 2, 3])]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:566)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1434)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1493)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1483)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1446)
> at
> org.apache.calcite.adapter.arrow.ArrowAdapterTest.testArrowProjectFieldsWithDisjunctiveFilter(ArrowAdapterTest.java:260)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
>
[jira] [Updated] (CALCITE-6414) Snowflake JDBC adapter should generate BOOLOR_AGG, BOOLAND_AGG for MAX, MIN on BOOLEAN values
[
https://issues.apache.org/jira/browse/CALCITE-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6414:
Labels: pull-request-available (was: )
> Snowflake JDBC adapter should generate BOOLOR_AGG, BOOLAND_AGG for MAX, MIN
> on BOOLEAN values
> -
>
> Key: CALCITE-6414
> URL: https://issues.apache.org/jira/browse/CALCITE-6414
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Justin Swett
>Assignee: Nitish Kumar
>Priority: Trivial
> Labels: pull-request-available
>
> The rewriteMacMInExpr is generating incorrect SQL for Snowflake.
> Instead of BOOL_OR, it should be BOOLOR_AGG and instead BOOL_AND, it should
> be BOOLAND_AGG
>
> I think adding the following expectation in testMaxMinOnBooleanColumn should
> repro:
>
> {code:java}
> @Test void testMaxMinOnBooleanColumn(){
> ...
> final String expectedSnowflake = "SELECT BOOLOR_AGG(\"brand_name\" =
> 'a'), "
> + "BOOLAND_AGG(\"brand_name\" = 'a'), "
> + "MIN(\"brand_name\")\n"
> + "FROM \"foodmart\".\"product\"";
> sql(query)
> .ok(expected)
> .withBigQuery().ok(expectedBigQuery)
> .withPostgresql().ok(expectedPostgres)
> .withSnowflak().ok(expectedSnowflake)
> .withRedshift().ok(expectedPostgres);
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5855) Implement frame exclusion in window functions
[
https://issues.apache.org/jira/browse/CALCITE-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5855:
Labels: pull-request-available (was: )
> Implement frame exclusion in window functions
> -
>
> Key: CALCITE-5855
> URL: https://issues.apache.org/jira/browse/CALCITE-5855
> Project: Calcite
> Issue Type: Bug
>Reporter: Itiel Sadeh
>Assignee: Itiel Sadeh
>Priority: Major
> Labels: pull-request-available
>
> PostgreSQL supports "frame exclusion" in window function, e.g. :
> {code:sql}
> SELECT sum(x) OVER (PARTITION BY y ORDER BY z ROWS BETWEEN UNBOUNDED
> PRECEDING and UNBOUNDED FOLLOWING EXCLUDE CURRENT ROW) from t
> {code}
> (see
> [here|https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS])
> which let you ignore some rows from the selected scope.
> This ticket is adding support for it in Calcite
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6428) Typo in adapter documentation
[ https://issues.apache.org/jira/browse/CALCITE-6428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6428: Labels: documentation pull-request-available (was: documentation) > Typo in adapter documentation > - > > Key: CALCITE-6428 > URL: https://issues.apache.org/jira/browse/CALCITE-6428 > Project: Calcite > Issue Type: Improvement >Reporter: Thad Guidry >Priority: Trivial > Labels: documentation, pull-request-available > Original Estimate: 5m > Remaining Estimate: 5m > > There's a typo `10:37` which should be `9:37` in the [Window > functions|https://calcite.apache.org/docs/adapter.html#window-functions] > section of `/docs/adapter.html` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6427) Use a higher precision for DECIMAL intermediate results for some aggregate functions like STDDEV
[ https://issues.apache.org/jira/browse/CALCITE-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6427: Labels: pull-request-available (was: ) > Use a higher precision for DECIMAL intermediate results for some aggregate > functions like STDDEV > > > Key: CALCITE-6427 > URL: https://issues.apache.org/jira/browse/CALCITE-6427 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.37.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > Today aggregates like STDDEV are expanded into computations that use > intermediate results with the same type as the input values. Since STDDEV > squares values, this precision may prove insufficient. For DECIMAL values a > reasonable approach would be to use double the input precision and scale. > This is also related to [CALCITE-6322], [CALCITE-4924], [CALCITE-6324] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6426) When performing starrocks dialect conversion for cast (xxx as int) and cast (xxx as bigint), it defaults to using MySQL dialect
[ https://issues.apache.org/jira/browse/CALCITE-6426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6426: Labels: pull-request-available (was: ) > When performing starrocks dialect conversion for cast (xxx as int) and cast > (xxx as bigint), it defaults to using MySQL dialect > --- > > Key: CALCITE-6426 > URL: https://issues.apache.org/jira/browse/CALCITE-6426 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.37.0 >Reporter: fanluo >Priority: Major > Labels: pull-request-available > Attachments: image-2024-06-03-19-57-22-686.png > > > When performing starrocks dialect conversion for cast (xxx as int) and cast > (xxx as bigint), it defaults to using MySQL dialect，like this: > !image-2024-06-03-19-57-22-686.png|width=839,height=123! > while starlocks does not explicitly declare support for the signed data type. > If conversion is performed according to the MySQL dialect by default, the > execution result will exceed expectations when the data value exceeds the > range [-21474836482147483647] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6424) Enable RLIKE function in MySQL library
[ https://issues.apache.org/jira/browse/CALCITE-6424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6424: Labels: pull-request-available (was: ) > Enable RLIKE function in MySQL library > -- > > Key: CALCITE-6424 > URL: https://issues.apache.org/jira/browse/CALCITE-6424 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.37.0 >Reporter: xiong duan >Assignee: xiong duan >Priority: Major > Labels: pull-request-available > Fix For: 1.38.0 > > > According to > [https://sqlfiddle.com/mysql/online-compiler?id=1bca82cf-ebb9-4100-8cec-302b688f7ba8]. > > And the Official Document about RLIKE > [https://dev.mysql.com/doc/refman/8.4/en/regexp.html#operator_regexp] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6244) Improve `Expressions#constant` to allow Java records
[
https://issues.apache.org/jira/browse/CALCITE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6244:
Labels: pull-request-available (was: )
> Improve `Expressions#constant` to allow Java records
>
>
> Key: CALCITE-6244
> URL: https://issues.apache.org/jira/browse/CALCITE-6244
> Project: Calcite
> Issue Type: Improvement
> Components: linq4j
>Reporter: Wegdan Ghazi
>Assignee: Wegdan Ghazi
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> To use
> [Expressions#constant|https://github.com/apache/calcite/blob/e17098d47f3c31e4d90cc17e6e1da1175bf49ae4/linq4j/src/main/java/org/apache/calcite/linq4j/tree/Expressions.java#L540]
> with complex models, it's required to pass a model with public fields, as
> can be seen in this
> [test|https://github.com/apache/calcite/blob/e17098d47f3c31e4d90cc17e6e1da1175bf49ae4/linq4j/src/test/java/org/apache/calcite/linq4j/test/ExpressionTest.java#L865].
> i.e. to successfully pass an instance of `{{{}Employee{}}}`, it must be
> defined as follows:
> {code:java}
> public static class Employee {
> public final int empno;
> public final String name;
> public final int deptno; public Employee(int empno, String name, int
> deptno) {
> this.empno = empno;
> this.name = name;
> this.deptno = deptno;
> } public String toString() {
> return "Employee(name: " + name + ", deptno:" + deptno + ")";
> } @Override public int hashCode() {
> final int prime = 31;
> int result = 1;
> result = prime * result + deptno;
> result = prime * result + empno;
> result = prime * result + ((name == null) ? 0 : name.hashCode());
> return result;
> } @Override public boolean equals(Object obj) {
> if (this == obj) {
> return true;
> }
> if (obj == null) {
> return false;
> }
> if (getClass() != obj.getClass()) {
> return false;
> }
> Employee other = (Employee) obj;
> if (deptno != other.deptno) {
> return false;
> }
> if (empno != other.empno) {
> return false;
> }
> if (name == null) {
> if (other.name != null) {
> return false;
> }
> } else if (!name.equals(other.name)) {
> return false;
> }
> return true;
> }
> } {code}
> This makes it difficult to use generated classes e.g. Java records or
> immutables, or even encapsulated POJOs to pass through Linq4j.
> This is caused by the logic to
> [explore|https://github.com/apache/calcite/blob/e17098d47f3c31e4d90cc17e6e1da1175bf49ae4/linq4j/src/main/java/org/apache/calcite/linq4j/tree/ConstantExpression.java#L299]
> and
> [create|https://github.com/apache/calcite/blob/e17098d47f3c31e4d90cc17e6e1da1175bf49ae4/linq4j/src/main/java/org/apache/calcite/linq4j/tree/ConstantExpression.java#L216]
> the model constructor; which depends on:
> {code:java}
> value.getClass().getFields() {code}
> which only accesses public fields.
> {*}Proposed solution{*}: Access fields using reflection, by accessing their
> getter methods.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6423) Invalid unparse for CHAR without precision in MySQLDialect
[
https://issues.apache.org/jira/browse/CALCITE-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6423:
Labels: pull-request-available (was: )
> Invalid unparse for CHAR without precision in MySQLDialect
> --
>
> Key: CALCITE-6423
> URL: https://issues.apache.org/jira/browse/CALCITE-6423
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> As code review comment in [https://github.com/apache/calcite/pull/3799.]
> Execute SQL :
> {code:java}
> select cast(product_id as char) from product{code}
> Expected MySQL SQL should be:
> {code:java}
> select cast(product_id as char) from product{code}
> But is:
> {code:java}
> select cast(product_id as char(1)) from product{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6411) Support Collect in ToLogicalConverter
[ https://issues.apache.org/jira/browse/CALCITE-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6411: Labels: pull-request-available (was: ) > Support Collect in ToLogicalConverter > - > > Key: CALCITE-6411 > URL: https://issues.apache.org/jira/browse/CALCITE-6411 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.37.0 >Reporter: Caican Cai >Priority: Minor > Labels: pull-request-available > Fix For: 1.38.0 > > > Support Collect operator expression convert to Logical in ToLogicalConverter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6369) Expanding "star" gives ArrayIndexOutOfBoundsException with redundant columns and USING
[
https://issues.apache.org/jira/browse/CALCITE-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6369:
Labels: pull-request-available (was: )
> Expanding "star" gives ArrayIndexOutOfBoundsException with redundant columns
> and USING
> --
>
> Key: CALCITE-6369
> URL: https://issues.apache.org/jira/browse/CALCITE-6369
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Claude Brisson
>Assignee: Norman Jordan
>Priority: Major
> Labels: pull-request-available
>
> The query
> {code}
> select r_regionkey, * from region r0 join region r1 using (r_regionkey)
> {code}
> produces
> {code}
> java.lang.ArrayIndexOutOfBoundsException: Index 14 out of bounds for length 14
> at org.apache.calcite.runtime.PairLists$ArrayImmutablePairList.get
> (PairLists.java:573)
> at org.apache.calcite.runtime.PairLists$ArrayImmutablePairList.get
> (PairLists.java:550)
> at org.apache.calcite.sql.validate.SqlValidatorImpl$Permute.permute
> (SqlValidatorImpl.java:7443)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar
> (SqlValidatorImpl.java:697)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem
> (SqlValidatorImpl.java:453)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList
> (SqlValidatorImpl.java:4658)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect
> (SqlValidatorImpl.java:3840)
> at org.apache.calcite.sql.validate.SelectNamespace.validateImpl
> (SelectNamespace.java:61)
> at org.apache.calcite.sql.validate.AbstractNamespace.validate
> (AbstractNamespace.java:88)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace
> (SqlValidatorImpl.java:1154)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery
> (SqlValidatorImpl.java:1125)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6310) Add REGEXP_REPLACE function (enabled in PostgreSQL library)
[ https://issues.apache.org/jira/browse/CALCITE-6310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6310: Labels: pull-request-available (was: ) > Add REGEXP_REPLACE function (enabled in PostgreSQL library) > --- > > Key: CALCITE-6310 > URL: https://issues.apache.org/jira/browse/CALCITE-6310 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Assignee: James Duong >Priority: Minor > Labels: pull-request-available > > * There is an existing implementation. > * PostgreSQL requires supporting an optional extra flags argument -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6422) RexLiteral.isNullLiteral should be applied before RexLiteral.booleanValue in SubstitutionVisitor.mayBeSatisfiable
[
https://issues.apache.org/jira/browse/CALCITE-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6422:
Labels: pull-request-available (was: )
> RexLiteral.isNullLiteral should be applied before RexLiteral.booleanValue in
> SubstitutionVisitor.mayBeSatisfiable
> -
>
> Key: CALCITE-6422
> URL: https://issues.apache.org/jira/browse/CALCITE-6422
> Project: Calcite
> Issue Type: Bug
>Reporter: Mou Wu
>Assignee: Mou Wu
>Priority: Major
> Labels: pull-request-available
>
> Add the test case in MaterializedViewRelOptRulesTest to reproduce this bug:
> {code:java}
> @Test public void testNpeInSplitFilterOfSubstitutionVisitor() {
> sql("select \"col1\", \"col2\""
> + " from \"nullables\""
> + " where \"col1\" <> \"col2\" and \"col3\" = 1",
> "select \"col1\", \"col2\""
> + " from \"nullables\""
> + " where \"col1\" = \"col2\" and \"col3\" = 1")
> .checkingThatResultContains(""
> + "EnumerableCalc(expr#0..2=[{inputs}], expr#3=[=($t0, $t1)],
> expr#4=[CAST($t2):INTEGER NOT NULL], expr#5=[1], expr#6=[=($t4, $t5)],
> expr#7=[AND($t3, $t6)], proj#0..1=[{exprs}], $condition=[$t7])\n"
> + " EnumerableTableScan(table=[[hr, nullables]])")
> .ok();
> } {code}
> A NPE will be thrown.
> Notes: col1 and col2 of table nullables should be nullable.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6419) Invalid unparse for VARCHAR without precision in HiveSqlDialect And SparkSqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6419:
Labels: pull-request-available (was: )
> Invalid unparse for VARCHAR without precision in HiveSqlDialect And
> SparkSqlDialect
> ---
>
> Key: CALCITE-6419
> URL: https://issues.apache.org/jira/browse/CALCITE-6419
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> When we execute SQL in Calcite:
> {code:java}
> select cast(product_id as varchar) from product;
> {code}
> Generage the HiveSQL\SparkSQL:
> {code:java}
> select cast(product_id as varchar) from product;
> {code}
> According to the
> [https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types#LanguageManualTypes-VarcharvarcharVarchar].
> In Hive, the varchar must have a precision.So when unpare VARCHAR without
> precision, I will convert VARCHAR to String. VARCHAR with precison do nothing.
> According to the
> [https://spark.apache.org/docs/latest/sql-ref-datatypes.html].
> In Spark, Same as Hive. But as note, It can only be used in table schema, not
> functions/operators. So I will convert VARCHAR with or without precision to
> String;
> In SparkSQL, Varchar with precision are not effective, but no error and just
> a warning:
> {code:java}
> spark-sql> select cast('value' as varchar(2));
> 24/05/24 16:04:39 WARN CharVarcharUtils: The Spark cast operator does not
> support char/varchar type and simply treats them as string type. Please use
> string type directly to avoid confusion. Otherwise, you can set
> spark.sql.legacy.charVarcharAsString to true, so that Spark treat them as
> string type as same as Spark 3.0 and earlier
> value
> Time taken: 2.797 seconds, Fetched 1 row(s){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6421) Calcite Avatica support JDK 22
[ https://issues.apache.org/jira/browse/CALCITE-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6421: Labels: pull-request-available (was: ) > Calcite Avatica support JDK 22 > -- > > Key: CALCITE-6421 > URL: https://issues.apache.org/jira/browse/CALCITE-6421 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Sergey Nuyanzin >Assignee: Sergey Nuyanzin >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6417) Map value constructor and Array value constructor unparsed incorrectly for HiveSqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6417:
Labels: pull-request-available (was: )
> Map value constructor and Array value constructor unparsed incorrectly for
> HiveSqlDialect
> -
>
> Key: CALCITE-6417
> URL: https://issues.apache.org/jira/browse/CALCITE-6417
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> The SQL：
> {code:java}
> SELECT MAP['k1', 'v1', 'k2', 'v2'],ARRAY[1, 2, 3]{code}
> Generate Hive SQL should be：
> {code:java}
> SELECT MAP ('k1', 'v1', 'k2', 'v2'),ARRAY (1, 2, 3){code}
> But is:
> {code:java}
> SELECT MAP['k1', 'v1', 'k2', 'v2'],ARRAY[1, 2, 3]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6370) AS operator problems with USING clause
[
https://issues.apache.org/jira/browse/CALCITE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6370:
Labels: pull-request-available (was: )
> AS operator problems with USING clause
> --
>
> Key: CALCITE-6370
> URL: https://issues.apache.org/jira/browse/CALCITE-6370
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Claude Brisson
>Assignee: Norman Jordan
>Priority: Major
> Labels: pull-request-available
>
> In some cases, with the {{USING}} clause, the used column generates ambiguity
> exceptions with the {{AS}} operator.
>
> OK : {{select r_regionkey from region r0 join region r1 using (r_regionkey)}}
> OK : {{select r_regionkey * 2 as rk2 from region r0 join region r1 using
> (r_regionkey)}}
> KO : {{select r_regionkey as rk from region r0 join region r1 using
> (r_regionkey)}}
>
> The last query generates the following error:
>
> {code:java}
> org.apache.calcite.sql.validate.SqlValidatorException: Column 'r_regionkey'
> is ambiguous
> at jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance
> (DirectConstructorHandleAccessor.java:62)
> at java.lang.reflect.Constructor.newInstanceWithCaller
> (Constructor.java:502)
> at java.lang.reflect.Constructor.newInstance (Constructor.java:486)
> at org.apache.calcite.runtime.Resources$ExInstWithCause.ex
> (Resources.java:507)
> at org.apache.calcite.runtime.Resources$ExInst.ex (Resources.java:601)
> at org.apache.calcite.sql.SqlUtil.newContextException (SqlUtil.java:948)
> at org.apache.calcite.sql.SqlUtil.newContextException (SqlUtil.java:933)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError
> (SqlValidatorImpl.java:5517)
> at org.apache.calcite.sql.validate.DelegatingScope.fullyQualify
> (DelegatingScope.java:296)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.findTableColumnPair
> (SqlValidatorImpl.java:3989)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.isRolledUpColumn
> (SqlValidatorImpl.java:4032)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp
> (SqlValidatorImpl.java:3945)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp
> (SqlValidatorImpl.java:3940)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp
> (SqlValidatorImpl.java:3959)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUpInSelectList
> (SqlValidatorImpl.java:3861)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect
> (SqlValidatorImpl.java:3849)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6416) Remove unnecessary SUBSTRING rewrite in SparkSqlDialect
[ https://issues.apache.org/jira/browse/CALCITE-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6416: Labels: pull-request-available (was: ) > Remove unnecessary SUBSTRING rewrite in SparkSqlDialect > --- > > Key: CALCITE-6416 > URL: https://issues.apache.org/jira/browse/CALCITE-6416 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.37.0 >Reporter: xiong duan >Assignee: xiong duan >Priority: Minor > Labels: pull-request-available > Fix For: 1.38.0 > > > SparkSqlDialect have a unnecessary rewrite about SUBSTRING func. > In CALCITE-3247, We handle the SUBSTRING rewrite in HiveSqlDialect. > In CALCITE-3072, We handle the SUBSTRING rewrite in SparkSqlDialect. > In CALCITE-5677, We refactor the SUBSTRING as the default behaviour and > remove the SUBSTRING rewrite in HiveSqlDialect. This PR will remove the Spark. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6415) Invalid unparse for TIMESTAMP with HiveSqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6415:
Labels: pull-request-available (was: )
> Invalid unparse for TIMESTAMP with HiveSqlDialect
> -
>
> Key: CALCITE-6415
> URL: https://issues.apache.org/jira/browse/CALCITE-6415
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> When parsing
> {code:java}
> SELECT CAST("2023-11-10" AS TIMESTAMP) {code}
> The unparsed Hive SQL query gives:
> {code:java}
> SELECT CAST("2023-11-10" AS TIMESTAMP(0)) {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6311) Support PostgreSQL DATE_PART
[
https://issues.apache.org/jira/browse/CALCITE-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6311:
Labels: pull-request-available (was: )
> Support PostgreSQL DATE_PART
>
>
> Key: CALCITE-6311
> URL: https://issues.apache.org/jira/browse/CALCITE-6311
> Project: Calcite
> Issue Type: Sub-task
>Reporter: James Duong
>Assignee: Norman Jordan
>Priority: Minor
> Labels: pull-request-available
>
> * PostgreSQL and Redshift let the date_part parameter be a string instead of
> a just an enum-like identifier (eg DATE_PART('year', ...) and DATE_PART(year,
> ...) are both supported.
> * SQL Server does not support using a string here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5737) Support JDK 20
[ https://issues.apache.org/jira/browse/CALCITE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5737: Labels: pull-request-available (was: ) > Support JDK 20 > -- > > Key: CALCITE-5737 > URL: https://issues.apache.org/jira/browse/CALCITE-5737 > Project: Calcite > Issue Type: Sub-task >Reporter: Julian Hyde >Priority: Major > Labels: pull-request-available > > Support JDK 20. > We currently support JDK (and OpenJDK) versions up to 18. (CALCITE-5747 will > add support for JDK 19.) JDK 20 is the latest. We should support JDK 20 in > Calcite 1.35 if possible, or soon after. > This change would modify history.md (for the upcoming release), add JDK 20 to > the GitHub CI, and fix the build. There are deprecation warnings (which we > treat as errors) regarding the java.net.URL constructor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6392) Support all PostgreSQL 14 date/time patterns for to_date/to_timestamp
[ https://issues.apache.org/jira/browse/CALCITE-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6392: Labels: pull-request-available (was: ) > Support all PostgreSQL 14 date/time patterns for to_date/to_timestamp > - > > Key: CALCITE-6392 > URL: https://issues.apache.org/jira/browse/CALCITE-6392 > Project: Calcite > Issue Type: Sub-task >Reporter: Norman Jordan >Assignee: Norman Jordan >Priority: Minor > Labels: pull-request-available > > Many of the date/time format patterns supported by PostgreSQL 14 are not > supported in Calcite. > * HH > * US > * > * S > * AM > * A.M. > * am > * a.m. > * PM > * P.M. > * pm > * p.m. > * Y,YYY > * YYY > * Y > * IYYY > * IYY > * IY > * I > * BC > * B.C. > * bc > * b.c. > * AD > * A.D. > * ad > * a.d. > * MONTH > * month > * MON > * mon > * DAY > * day > * Dy > * dy > * IDDD > * ID > * TZH > * TZM > * OF > There are also template pattern modifiers that need to be supported. > * FM (prefix) > * TH (suffix) > * th (suffix) > * FX (prefix) > * TM (prefix) > Some format patterns in Calcite behave differently from PostgreSQL 14. > * FF1 > * FF2 > * FF4 > * FF5 > * FF6 > Also verify that the other existing format strings produce results that match > PostgreSQL 14. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6380) Casts from INTERVAL and STRING to DECIMAL are incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6380: Labels: pull-request-available (was: ) > Casts from INTERVAL and STRING to DECIMAL are incorrect > --- > > Key: CALCITE-6380 > URL: https://issues.apache.org/jira/browse/CALCITE-6380 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > This is a follow-up from [CALCITE-6322], which is about casts from numeric > types to DECIMAL values. There are two tests in SqlOperatorTest which are > disabled due to this bug: > - testCastStringToDecimal > - testCastIntervalToNumeric -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6400) MAP_ENTRIES is not allowed to be empty
[
https://issues.apache.org/jira/browse/CALCITE-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6400:
Labels: pull-request-available (was: )
> MAP_ENTRIES is not allowed to be empty
> --
>
> Key: CALCITE-6400
> URL: https://issues.apache.org/jira/browse/CALCITE-6400
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> {code:java}
> scala> val df = spark.sql("select map_entries(map('foo', 1, null, 2.0))")
> df: org.apache.spark.sql.DataFrame = [map_entries(map(foo, 1, NULL, 2.0)):
> array>]
> scala> df.show()
> org.apache.spark.SparkRuntimeException: [NULL_MAP_KEY] Cannot use null as map
> key.
> at
> org.apache.spark.sql.errors.QueryExecutionErrors$.nullAsMapKeyNotAllowedError(QueryExecutionErrors.scala:445)
> at
> org.apache.spark.sql.catalyst.util.ArrayBasedMapBuilder.put(ArrayBasedMapBuilder.scala:56)
> at
> org.apache.spark.sql.catalyst.expressions.CreateMap.eval(complexTypeCreator.scala:248)
> at
> org.apache.spark.sql.catalyst.expressions.UnaryExpression.eval(Expression.scala:542)
> at
> org.apache.spark.sql.catalyst.expressions.UnaryExpression.eval(Expression.scala:542)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$.org$apache$spark$sql$catalyst$optimizer$ConstantFolding$$constantFolding(expressions.scala:80)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$.$anonfun$constantFolding$4(expressions.scala:90)
> at
> org.apache.spark.sql.catalyst.trees.UnaryLike.mapChildren(TreeNode.scala:1249)
> at
> org.apache.spark.sql.catalyst.trees.UnaryLike.mapChildren$(TreeNode.scala:1248)
> at
> org.apache.spark.sql.catalyst.expressions.UnaryExpression.mapChildren(Expression.scala:532)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$.org$apache$spark$sql$catalyst$optimizer$ConstantFolding$$constantFolding(expressions.scala:90)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$$anonfun$apply$1.$anonfun$applyOrElse$1(expressions.scala:94)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.$anonfun$mapExpressions$1(QueryPlan.scala:207)
> at
> org.apache.spark.sql.catalyst.trees.CurrentOrigin$.withOrigin(TreeNode.scala:104)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.transformExpression$1(QueryPlan.scala:207)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.recursiveTransform$1(QueryPlan.scala:218)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.$anonfun$mapExpressions$3(QueryPlan.scala:223)
> at
> scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:286)
> at scala.collection.immutable.List.foreach(List.scala:431)
> at scala.collection.TraversableLike.map(TraversableLike.scala:286)
> at scala.collection.TraversableLike.map$(TraversableLike.scala:279)
> at scala.collection.immutable.List.map(List.scala:305)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.recursiveTransform$1(QueryPlan.scala:223)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.$anonfun$mapExpressions$4(QueryPlan.scala:228)
> at
> org.apache.spark.sql.catalyst.trees.TreeNode.mapProductIterator(TreeNode.scala:355)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.mapExpressions(QueryPlan.scala:228)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$$anonfun$apply$1.applyOrElse(expressions.scala:94)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$$anonfun$apply$1.applyOrElse(expressions.scala:93)
> at
> org.apache.spark.sql.catalyst.trees.TreeNode.$anonfun$transformDownWithPruning$1(TreeNode.scala:512)
> at
> org.apache.spark.sql.catalyst.trees.CurrentOrigin$.withOrigin(TreeNode.scala:104)
> at
> org.apache.spark.sql.catalyst.trees.TreeNode.transformDownWithPruning(TreeNode.scala:512)
> at
> org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.org$apache$spark$sql$catalyst$plans$logical$AnalysisHelper$$super$transformDownWithPruning(LogicalPlan.scala:31)
> at
> org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper.transformDownWithPruning(AnalysisHelper.scala:267)
> at
> org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper.transformDownWithPruning$(AnalysisHelper.scala:263)
> at
> org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.transformDownWithPruning(LogicalPlan.scala:31)
> at
> org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.transformDownWithPruning(LogicalPlan.scala:31)
> at
> org.apache.spark.sql.catalyst.trees.TreeNode.transformWithPruning(TreeNode.scala:478)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$.apply(expressions.scala:93)
> at
>
[jira] [Updated] (CALCITE-6352) The map_contains_key function may return true when the key and mapkeytype types are different.
[
https://issues.apache.org/jira/browse/CALCITE-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6352:
Labels: pull-request-available (was: )
> The map_contains_key function may return true when the key and mapkeytype
> types are different.
> --
>
> Key: CALCITE-6352
> URL: https://issues.apache.org/jira/browse/CALCITE-6352
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Assignee: Caican Cai
>Priority: Critical
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
>
> {code:java}
> scala> val df = spark.sql("select map_contains_key(map(1, 'a', 2, 'b'),
> 2.0)")
> val df: org.apache.spark.sql.DataFrame = [map_contains_key(map(1, a, 2, b),
> 2.0): boolean]
> scala> df.show()
> +--+
> |map_contains_key(map(1, a, 2, b), 2.0)|
> +--+
> | true|
> +--+
> {code}
> calcite return false
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6397) Add NVL2 function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6397: Labels: pull-request-available (was: ) > Add NVL2 function (enabled in Spark library) > > > Key: CALCITE-6397 > URL: https://issues.apache.org/jira/browse/CALCITE-6397 > Project: Calcite > Issue Type: New Feature >Reporter: Caican Cai >Priority: Major > Labels: pull-request-available > > Add NVL2 function (enabled in Spark library) > > https://spark.apache.org/docs/2.3.0/api/sql/index.html#nvl2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6396) Add ADD_MONTHS function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6396: Labels: pull-request-available (was: ) > Add ADD_MONTHS function (enabled in Spark library) > -- > > Key: CALCITE-6396 > URL: https://issues.apache.org/jira/browse/CALCITE-6396 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.36.0 >Reporter: Caican Cai >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > > Add ADD_MONTHS function (enabled in Spark library) > > https://spark.apache.org/docs/2.3.0/api/sql/index.html#add_months -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6393) Byte code of SqlFunctions is invalid
[
https://issues.apache.org/jira/browse/CALCITE-6393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6393:
Labels: pull-request-available (was: )
> Byte code of SqlFunctions is invalid
>
>
> Key: CALCITE-6393
> URL: https://issues.apache.org/jira/browse/CALCITE-6393
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Sergey Nuyanzin
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> The issue is a result of testing of Apache Calcite 1.37.0 rc 4 in this thread
> [1]
> There is test project andprocedure provided by [~MasseGuillaume] [2] (see
> also original thread where this was first discussed [3])
> it shows that since Calcite 1.36.0 it starts failing as
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: Index 65536 out of bounds for
> length 297
> at org.objectweb.asm.ClassReader.readLabel(ClassReader.java:2695)
> at org.objectweb.asm.ClassReader.createLabel(ClassReader.java:2711)
> at
> org.objectweb.asm.ClassReader.readTypeAnnotations(ClassReader.java:2777)
> at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1929)
> at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1515)
> at org.objectweb.asm.ClassReader.accept(ClassReader.java:745)
> {noformat}
> Also since Calcite 1.27.0 it starts failing as
> {noformat}
> java.lang.IllegalArgumentException: Invalid end label (must be visited
> first)
> at
> org.objectweb.asm.util.CheckMethodAdapter.checkLabel(CheckMethodAdapter.java:1453)
> at
> org.objectweb.asm.util.CheckMethodAdapter.visitLocalVariableAnnotation(CheckMethodAdapter.java:996)
> at
> org.objectweb.asm.MethodVisitor.visitLocalVariableAnnotation(MethodVisitor.java:757)
> at
> org.objectweb.asm.commons.MethodRemapper.visitLocalVariableAnnotation(MethodRemapper.java:257)
> at org.objectweb.asm.ClassReader.readCode(ClassReader.java:2614)
> at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1515)
> {noformat}
> [1] https://lists.apache.org/thread/n6cs1l86mt6fc5q8pcxr97czs3p6w65f
> [2] https://github.com/MasseGuillaume/asm-remapper-bug
> [3] https://lists.apache.org/thread/o736wz4qnr4l285bj5gv073cy0qll9t0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6395) Significant precision loss when representing REAL literals
[
https://issues.apache.org/jira/browse/CALCITE-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6395:
Labels: pull-request-available (was: )
> Significant precision loss when representing REAL literals
> --
>
> Key: CALCITE-6395
> URL: https://issues.apache.org/jira/browse/CALCITE-6395
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> Consider this test that could be a SqlOperatorTest:
> {code:java}
> f.checkScalar("CAST(CAST('36854775807.0' AS REAL) AS BIGINT)",
> "36854775808", "BIGINT NOT NULL");
> {code}
> The produced result is actually very far:
> Expected: is "36854775808"
> but: was "36854779904"
> This big error comes from two reasons:
> - Calcite uses BigDecimal values to represent floating point values, see
> [CALCITE-2067]
> - When converting a Float value to a BigDecimal in RexBuilder.clean(), the
> following sequence is used:
> {code:java}
> new BigDecimal(((Number) o).doubleValue(), MathContext.DECIMAL32)
> {code}
> Using a DECIMAL32 math context leads to the precision loss. Just because a
> Float uses 32 bits does not mean that the decimal should also use 32 bits.
> The real fix is in the PR for [CALCITE-2067], but that hasn't been reviewed
> for a long time, so I will submit a fix for the clean() method..
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6376) Filtering CTE of at least 6 columns with QUALIFY operation results in exception
[
https://issues.apache.org/jira/browse/CALCITE-6376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6376:
Labels: pull-request-available (was: )
> Filtering CTE of at least 6 columns with QUALIFY operation results in
> exception
> ---
>
> Key: CALCITE-6376
> URL: https://issues.apache.org/jira/browse/CALCITE-6376
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Austin Richardson
>Assignee: ShenDa
>Priority: Major
> Labels: pull-request-available
>
> Example query:
>
> {code:java}
> WITH MyCTE AS (
> SELECT
> column1,
> column2,
> column3,
> column4,
> column5,
> column6
> FROM (
> VALUES
> ('value1', 10, 5.0, 'data1', 'info1', 'test1'),
> ('value2', 20, 4.0, 'data2', 'info2', 'test2'),
> ('value3', 30, 3.0, 'data3', 'info3', 'test3'),
> ('value4', 40, 2.0, 'data4', 'info4', 'test4'),
> ('value5', 50, 1.0, 'data5', 'info5', 'test5')
> ) AS t(column1, column2, column3, column4, column5, column6)
> )
> SELECT *
> FROM MyCTE
> QUALIFY RANK() OVER (ORDER BY column3) = 1{code}
>
> And exception snippet:
>
> {code:java}
> Caused by: java.lang.ClassCastException: class
> org.apache.calcite.rex.RexInputRef cannot be cast to class
> java.lang.Comparable (org.apache.calcite.rex.RexInputRef is in unnamed module
> of loader org.springframework.boot.loader.LaunchedURLClassLoader @257f30f7;
> java.lang.Comparable is in module java.base of loader 'bootstrap')
> at
> org.apache.calcite.runtime.FlatLists$ComparableListImpl.get(FlatLists.java:1319)
> at
> org.apache.calcite.runtime.FlatLists$ComparableListImpl.get(FlatLists.java:1309)
> at
> java.base/java.util.AbstractList$Itr.next(AbstractList.java:373){code}
>
> Either removing one of the columns or the QUALIFY filter results in a
> successful query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6390) ArrowAdapterTest fails on Windows
[
https://issues.apache.org/jira/browse/CALCITE-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6390:
Labels: pull-request-available (was: )
> ArrowAdapterTest fails on Windows
> -
>
> Key: CALCITE-6390
> URL: https://issues.apache.org/jira/browse/CALCITE-6390
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Sergey Nuyanzin
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> -That's seems somehow highlights the difference between Windows Server and
> non Server-
> -we have tests against Windows Server on gha (windows-latest) and they are
> green-
> -At the same time local tests on Windows 11 show that {{ArrowAdapterTest}}
> fails like-
> Based on deeper analysis Arrow module was never tested on Windows since for
> Windows conf on gha it is {{--exclude-task :arrow:build}} which makes it
> skipping the tests for this module
> https://github.com/apache/calcite/blob/aa8d81bf1ff39e3632aeb856fc4cc247ce9727e5/.github/workflows/main.yml#L110C60-L110C88
> Any attempt to test it leads to
> {noformat}
> FAILURE 0.0sec, org.apache.calcite.adapter.arrow.ArrowAdapterTest >
> executionError
> java.io.IOException: Failed to delete temp directory
> D:\MyConfiguration\cancai.cai\AppData\Local\Temp\junit5105379620525559011.
> The following paths could not be deleted (see suppressed exceptions for
> details): , arrow
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.createIOExceptionWithAttachedFailures(TempDirectory.java:350)
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.close(TempDirectory.java:251)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.lambda$closeAllStoredCloseableValues$3(ExtensionValuesStore.java:68)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:390)
> at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.closeAllStoredCloseableValues(ExtensionValuesStore.java:68)
> at
> org.junit.jupiter.engine.descriptor.AbstractExtensionContext.close(AbstractExtensionContext.java:80)
> at
> org.junit.jupiter.engine.execution.JupiterEngineExecutionContext.close(JupiterEngineExecutionContext.java:53)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:222)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:57)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$cleanUp$10(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.cleanUp(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:98)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.invokeAll(ForkJoinPoolHierarchicalTestExecutorService.java:129)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
> at
>
[jira] [Updated] (CALCITE-6388) PsTableFunction throws NumberFormatException when the 'user' column has spaces
[
https://issues.apache.org/jira/browse/CALCITE-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6388:
Labels: pull-request-available (was: )
> PsTableFunction throws NumberFormatException when the 'user' column has spaces
> --
>
> Key: CALCITE-6388
> URL: https://issues.apache.org/jira/browse/CALCITE-6388
> Project: Calcite
> Issue Type: Bug
> Components: os-adapter
>Affects Versions: 1.36.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Line parsing splits on spaces
> ([PsTableFunction.java#L77|https://github.com/apache/calcite/blob/aa8d81bf1ff39e3632aeb856fc4cc247ce9727e5/plus/src/main/java/org/apache/calcite/adapter/os/PsTableFunction.java#L77]),
> which breaks whenever the "user" contains at least a space.
> An example output on my laptop is as follows:
> {noformat}
> $ ps ax -o
> ppid=,pid=,pgid=,tpgid=,stat=,user=,pcpu=,pmem=,vsz=,rss=,tty=,start=,time=,uid=,ruid=,sess=,comm=
> | grep startup
> 1 6728 6728 0 S startup user 0.0 0.0 410266096 2528 ??
> 11Apr24 0:16.97 501 501 0 /usr/sbin/distnoted
> 1 6729 6729 0 SN startup user 0.0 0.1 410332256 17616 ??
> 11Apr24 0:42.41 501 501 0
> /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Versions/A/Support/mdbulkimport
> 1 6750 6750 0 S startup user 0.0 0.0 410376144 13344 ??
> 11Apr24 0:40.39 501 501 0 /usr/libexec/lsd
> 1 10148 10148 0 S startup user 0.0 0.0 410354816 5488 ??
> 8:26PM 0:00.31 501 501 0 /usr/libexec/containermanagerd
> 1 95313 95313 0 S startup user 0.0 0.0 410357344 6576 ??
> Fri05PM 0:00.32 501 501 0 /usr/libexec/trustd{noformat}
> When running the test it fails with the following stack trace:
> {code:java}
> Error while executing SQL "select distinct `user` from ps": while parsing
> value [user] of field [pcpu] in line [ 1 6728 6728 0 S startup
> user 0.0 0.0 410266096 2528 ?? 11Apr24 0:16.95 501 501
> 0 /usr/sbin/distnoted]
> java.sql.SQLException: Error while executing SQL "select distinct `user` from
> ps": while parsing value [user] of field [pcpu] in line [ 1 6728 6728
> 0 S startup user 0.0 0.0 410266096 2528 ?? 11Apr24
> 0:16.95 501 501 0 /usr/sbin/distnoted]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:566)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1434)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1493)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1483)
> at
> org.apache.calcite.adapter.os.OsAdapterTest.testPsDistinct(OsAdapterTest.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
>
[jira] [Updated] (CALCITE-6387) Calcite build while compiliation with jdk11+
[
https://issues.apache.org/jira/browse/CALCITE-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6387:
Labels: pull-request-available (was: )
> Calcite build while compiliation with jdk11+
>
>
> Key: CALCITE-6387
> URL: https://issues.apache.org/jira/browse/CALCITE-6387
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Sergey Nuyanzin
>Priority: Major
> Labels: pull-request-available
>
> The issue appears with newly added Arrow adapter which requires
> {noformat}
> --add-opens=java.base/java.nio=ALL-UNNAMED
> {noformat}
> could be fixed with adding
> {noformat}
> plugins.withType {
> tasks {
> configureEach {
> jvmArgs("-XX:+IgnoreUnrecognizedVMOptions")
> jvmArgs("--add-opens=java.base/java.nio=ALL-UNNAMED")
> }
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
