[jira] [Updated] (CALCITE-5708) Change SUBSTRING result if either of parameters is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5708:
Labels: pull-request-available (was: )
> Change SUBSTRING result if either of parameters is NULL
> ---
>
> Key: CALCITE-5708
> URL: https://issues.apache.org/jira/browse/CALCITE-5708
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: pull-request-available
>
> According to standard:
> {noformat}
> 6.18
> ...
> 3)If is specified, then:
> ...
> c) If either C, S, or L is the null value, then the result of the substring function> is
> the null value.
> {noformat}
> calcite not follow this rule for now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5668) When parsing SQL in PostgreSQL dialect, allow unquoted table names to contain dollar sign, letters with diacritical marks and non-Latin letters
[ https://issues.apache.org/jira/browse/CALCITE-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5668: Labels: pull-request-available (was: ) > When parsing SQL in PostgreSQL dialect, allow unquoted table names to contain > dollar sign, letters with diacritical marks and non-Latin letters > --- > > Key: CALCITE-5668 > URL: https://issues.apache.org/jira/browse/CALCITE-5668 > Project: Calcite > Issue Type: Bug > Components: babel >Affects Versions: 1.34.0 >Reporter: Dmitry Sysolyatin >Priority: Major > Labels: pull-request-available > > According PostgreSQL documentation [1][2]: > ??SQL identifiers and key words must begin with a letter (a-z, but also > letters with diacritical marks and non-Latin letters) or an underscore (_). > Subsequent characters in an identifier or key word can be letters, > underscores, digits (0-9), or dollar signs ($).?? > Letters with diacritical marks and non-Latin letters are extended ascii > letters (character code 128-255 or in octal \200-\377)[3]. > [1] > [https://www.postgresql.org/docs/15/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS] > [2] > [https://github.com/postgres/postgres/blob/master/src/backend/parser/scan.l] > [3] > [https://learn.microsoft.com/zh-cn/office/vba/language/reference/user-interface-help/character-set-128255] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5714) Add MAP_ENTRIES for Spark dialect
[ https://issues.apache.org/jira/browse/CALCITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5714: Labels: pull-request-available (was: ) > Add MAP_ENTRIES for Spark dialect > - > > Key: CALCITE-5714 > URL: https://issues.apache.org/jira/browse/CALCITE-5714 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.35.0 >Reporter: jackylau >Priority: Major > Labels: pull-request-available > Fix For: 1.35.0 > > > MAP_ENTRIES - Returns an unordered array of all entries in the given map. > For more details > [https://spark.apache.org/docs/latest/sql-ref-functions-builtin.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5717) Prune Project's input if project has no InputRef and the input has 1 row
[
https://issues.apache.org/jira/browse/CALCITE-5717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5717:
Labels: pull-request-available (was: )
> Prune Project's input if project has no InputRef and the input has 1 row
>
>
> Key: CALCITE-5717
> URL: https://issues.apache.org/jira/browse/CALCITE-5717
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Benchao Li
>Assignee: Benchao Li
>Priority: Major
> Labels: pull-request-available
>
> The idea is to improve SQL
> {code:sql}
> select 1 from emps group by ()
> {code}
> In this case, we can safely prune the Aggregate.
> This idea is brought up in the discussion of CALCITE-5506
> We can add this improvement to ProjectAggregateMergeRule
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5704) Add ARRAY_EXCEPT, ARRAY_INTERSECT and ARRAY_UNION for Spark dialect
[ https://issues.apache.org/jira/browse/CALCITE-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5704: Labels: pull-request-available (was: ) > Add ARRAY_EXCEPT, ARRAY_INTERSECT and ARRAY_UNION for Spark dialect > --- > > Key: CALCITE-5704 > URL: https://issues.apache.org/jira/browse/CALCITE-5704 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.35.0 >Reporter: jackylau >Priority: Major > Labels: pull-request-available > Fix For: 1.35.0 > > > array_union(array1, array2) - Returns an array of the elements in the union > of array1 and array2, without duplicates. > array_intersect(array1, array2) - Returns an array of the elements in the > intersection of array1 and array2, without duplicates. > array_except(array1, array2) - Returns an array of the elements in array1 but > not in array2, without duplicates. > For more details > [https://spark.apache.org/docs/latest/api/sql/index.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5707) Add ARRAY_CONTAINS for Spark dialect
[ https://issues.apache.org/jira/browse/CALCITE-5707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5707: Labels: pull-request-available (was: ) > Add ARRAY_CONTAINS for Spark dialect > > > Key: CALCITE-5707 > URL: https://issues.apache.org/jira/browse/CALCITE-5707 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.34.0 >Reporter: jackylau >Assignee: jackylau >Priority: Major > Labels: pull-request-available > Fix For: 1.35.0 > > > ARRAY_CONTAINS - Returns true if the array contains the value > For more details > [https://spark.apache.org/docs/latest/sql-ref-functions-builtin.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5708) Change SUBSTRING result if either of parameters is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5708:
Labels: patch-available pull-request-available (was: patch-available)
> Change SUBSTRING result if either of parameters is NULL
> ---
>
> Key: CALCITE-5708
> URL: https://issues.apache.org/jira/browse/CALCITE-5708
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: patch-available, pull-request-available
>
> According to standard:
> {noformat}
> 6.18
> ...
> 3)If is specified, then:
> ...
> c) If either C, S, or L is the null value, then the result of the substring function> is
> the null value.
> {noformat}
> calcite not follow this rule for now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5698) EXTRACT from INTERVAL partially does not follow the SQL standard
[
https://issues.apache.org/jira/browse/CALCITE-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5698:
Labels: pull-request-available (was: )
> EXTRACT from INTERVAL partially does not follow the SQL standard
>
>
> Key: CALCITE-5698
> URL: https://issues.apache.org/jira/browse/CALCITE-5698
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: pull-request-available
>
> From SQL standard we can found:
> {noformat}
> ISO/IEC 9075-2:1999 (E)
> 6.17 :
> If is a , then the result is the
> value of the datetime
> field identified by that and has the same sign as
> the source>.{noformat}
> other data bases are follow this rule, i.e. :
> {noformat}
> SELECT
> EXTRACT (MONTH FROM INTERVAL '-1' MONTH)
> FROM
> DUAL;{noformat}
> returns: *-1*
> and ** the other one:
> {noformat}
> SELECT EXTRACT(MONTH FROM INTERVAL '-1 MONTHS'){noformat}
> return the same result,
> while calcite:
> {noformat}
> SELECT EXTRACT(MONTH FROM INTERVAL -1 MONTHS) AS extracted;{noformat}
> {noformat}
> < +-+
> < | -1 |
> < +-+
> ---
> > +---+
> > | 11 |
> > +---+{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5700) Add ARRAY_SIZE and ARRAY_REPEAT for Spark dialect
[ https://issues.apache.org/jira/browse/CALCITE-5700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5700: Labels: pull-request-available (was: ) > Add ARRAY_SIZE and ARRAY_REPEAT for Spark dialect > - > > Key: CALCITE-5700 > URL: https://issues.apache.org/jira/browse/CALCITE-5700 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.35.0 >Reporter: jackylau >Priority: Major > Labels: pull-request-available > Fix For: 1.35.0 > > > ARRAY_SIZE - Returns the size of an array. > ARRAY_REPEAT - Returns the array containing element count times. > > For more details > https://spark.apache.org/docs/latest/api/sql/index.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5699) Posix regex expressions failed while NOT operator is executed with null literals.
[
https://issues.apache.org/jira/browse/CALCITE-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5699:
Labels: pull-request-available (was: )
> Posix regex expressions failed while NOT operator is executed with null
> literals.
> -
>
> Key: CALCITE-5699
> URL: https://issues.apache.org/jira/browse/CALCITE-5699
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: pull-request-available
>
> Operations like :
> {noformat}
> SELECT null !~ 'ab[cd]'
> SELECT 'abcd' !~ null
> SELECT null !~ null
> SELECT null !~* 'ab[cd]'
> SELECT 'abcd' !~* null
> SELECT null !~* null{noformat}
> is not possible for now, NPE is raised :
> {noformat}
> Caused by: java.lang.NullPointerException
> at java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1770)
> at java.base/java.util.regex.Matcher.reset(Matcher.java:416)
> at java.base/java.util.regex.Matcher.(Matcher.java:253)
> at java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
> at
> org.apache.calcite.runtime.SqlFunctions.posixRegex(SqlFunctions.java:864){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5691) IN sub-query inside FILTER clause throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CALCITE-5691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5691:
Labels: pull-request-available (was: )
> IN sub-query inside FILTER clause throws IndexOutOfBoundsException
> --
>
> Key: CALCITE-5691
> URL: https://issues.apache.org/jira/browse/CALCITE-5691
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.34.0
> Environment: SqlLine
>Reporter: Soumyava Das
>Assignee: Runkang He
>Priority: Major
> Labels: pull-request-available
>
> I tried a query which is similar to the one I use in the sqlline component
> and I see the query still to fail. The query is
> {code:sql}
> SELECT
> count(*) FILTER (WHERE trim(both from name) IN (SELECT city FROM emps))
> FROM emps; {code}
> {code:sql}
> 0: jdbc:calcite:model=src/test/resources/mode> SELECT * FROM emps;
> +---+---+++---+---+--+-+-++
> | EMPNO | NAME | DEPTNO | GENDER | CITY | EMPID | AGE | SLACKER |
> MANAGER | JOINEDAT |
> +---+---+++---+---+--+-+-++
> | 100 | Fred | 10 || | 30| 25 | true|
> false | 1996-08-03 |
> | 110 | Eric | 20 | M | San Francisco | 3 | 80 | |
> false | 2001-01-01 |
> | 110 | John | 40 | M | Vancouver | 2 | null | false |
> true| 2002-05-03 |
> | 120 | Wilma | 20 | F | | 1 | 5| |
> true| 2005-09-07 |
> | 130 | Alice | 40 | F | Vancouver | 2 | null | false |
> true| 2007-01-01 |
> +---+---+++---+---+--+-+-++
> 5 rows selected (0.025 seconds)
> 0: jdbc:calcite:model=src/test/resources/mode> SELECT
> . . . . . . . . . . . . . . . . . . semicolon> count(*) FILTER (WHERE
> trim(both FROM name) IN (SELECT city FROM emps))
> . . . . . . . . . . . . . . . . . . semicolon> FROM emps;
> Error: Error while executing SQL "select
> count(*) filter (where trim(both from name) in (select city from emps))
> from emps": index (1) must be less than size (1) (state=,code=0){code}
> The stack trace that I typically see for this is
> {code:sql}
> java.lang.IndexOutOfBoundsException: index (1) must be less than size (1)
> at
> com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:313)
>at
> com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:295)
>at
> com.google.common.collect.SingletonImmutableList.get(SingletonImmutableList.java:45)
> at
> org.apache.calcite.plan.RelOptPredicateList.isEffectivelyNotNull(RelOptPredicateList.java:240)
>at
> org.apache.calcite.rex.RexSimplify.simplifyIs2(RexSimplify.java:911) at
> org.apache.calcite.rex.RexSimplify.simplifyIs1(RexSimplify.java:869) at
> org.apache.calcite.rex.RexSimplify.simplifyIs(RexSimplify.java:840) at
> org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:301)at
> org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:248)
> at
> org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:187)
> at
> org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:182)
> at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:1993)
> at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1840)at
> org.apache.calcite.tools.RelBuilder.projectNamed(RelBuilder.java:2161)
> at org.apache.calcite.tools.RelBuilder.projectNamed(RelBuilder.java:2098)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.createAggImpl(SqlToRelConverter.java:3464)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertAgg(SqlToRelConverter.java:3367)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:754)
>at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:680)
>at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3765)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:600)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5678) Calcite should reject date literals not satisfying Gregorian calendar, per SQL standard
[
https://issues.apache.org/jira/browse/CALCITE-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5678:
Labels: patch-available pull-request-available (was: patch-available)
> Calcite should reject date literals not satisfying Gregorian calendar, per
> SQL standard
> ---
>
> Key: CALCITE-5678
> URL: https://issues.apache.org/jira/browse/CALCITE-5678
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.34.0
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: patch-available, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> RexToLixTranslator now process datetime input\output string representation
> through transformation between gregorian and julian [1] calendars , thus no
> exception is raised if incorrect string is passed, just smart transformation
> instead.
> [1] org.apache.calcite.avatica.util.DateTimeUtils#timestampStringToUnixDate
> {noformat}
> create table t (i int not null, j timestamp);
> insert into t values (1, '2013-20-14 00:00:00');
> select * from t;
> > +---+-+
> > | I | J |
> > +---+-+
> > | 1 | 2014-08-16 00:00:00 |
> > +---+-+{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5695) Add MAP_KEYS and MAP_VALUES for Spark dialect
[
https://issues.apache.org/jira/browse/CALCITE-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5695:
Labels: pull-request-available (was: )
> Add MAP_KEYS and MAP_VALUES for Spark dialect
> -
>
> Key: CALCITE-5695
> URL: https://issues.apache.org/jira/browse/CALCITE-5695
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: jackylau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> {{MAP_KEYS}} - Returns an unordered array containing the keys of the map. If
> the map itself is null, the function will return null.
> {{MAP_VALUES}} - Returns an unordered array containing the values of the map.
> If the map itself is null, the function will return null.
> For more details
> [https://spark.apache.org/docs/latest/sql-ref-functions-builtin.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5683) Two level nested correlated subquery throws an exception during decorrelation.
[
https://issues.apache.org/jira/browse/CALCITE-5683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5683:
Labels: pull-request-available (was: )
> Two level nested correlated subquery throws an exception during
> decorrelation.
> ---
>
> Key: CALCITE-5683
> URL: https://issues.apache.org/jira/browse/CALCITE-5683
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.33.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: pull-request-available
>
> The following two level nested query is throwing an exception.
> {code:java}
> SELECT
> x_19 * (SELECT Max(main.x_111)
> FROM t1 main
> WHERE main.x_11 = t194.x_20
> AND main.x_12 = 'AFRICA'
> AND main.x_13 = (SELECT Max(rc.x_18)
> FROM t184 rc
> WHERE rc.x_15 = main.x_11
> AND rc.x_16 = main.x_12
> AND rc.x_17 = main.x_13
> AND rc.x_18 <= t194.x_22))
> FROM t194 {code}
> Following is the stack trace and the calcite version we are using is 1.33
> {code:java}
> java.lang.NullPointerException: cm.mapCorToCorRel.get($cor1)
> at java.util.Objects.requireNonNull(Objects.java:290)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.getCorRel(RelDecorrelator.java:928)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.createValueGenerator(RelDecorrelator.java:820)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateInputWithValueGenerator(RelDecorrelator.java:1028)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.maybeAddValueGenerator(RelDecorrelator.java:947)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:1150)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:1116)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:531)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.getInvoke(RelDecorrelator.java:707)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:749)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:738)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:531)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.getInvoke(RelDecorrelator.java:707)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:512)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:495)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:531)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.getInvoke(RelDecorrelator.java:707)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:1291)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:1270)
> 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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:531)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.getInvoke(RelDecorrelator.java:707)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:749)
> at
>
[jira] [Updated] (CALCITE-5602) Implement CSC and SEC function
[ https://issues.apache.org/jira/browse/CALCITE-5602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5602: Labels: pull-request-available (was: ) > Implement CSC and SEC function > -- > > Key: CALCITE-5602 > URL: https://issues.apache.org/jira/browse/CALCITE-5602 > Project: Calcite > Issue Type: Sub-task >Reporter: Dan Zou >Assignee: Dan Zou >Priority: Major > Labels: pull-request-available > > CSC(X): Computes the cosecant of the input angle, which is in radians. > SEC(X): Computes the secant for the angle of X, where X is specified in > radians. > See more details in BigQuery doc: > [CSC|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#csc] > and > [SEC|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#sec] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5693) AssertionError with UNION using CTE
[
https://issues.apache.org/jira/browse/CALCITE-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5693:
Labels: pull-request-available (was: )
> AssertionError with UNION using CTE
> ---
>
> Key: CALCITE-5693
> URL: https://issues.apache.org/jira/browse/CALCITE-5693
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> Adding the following test to {{JdbcAdapterTest}}
> {code:java}
> @Test void testFilterUnionIncludingWithPlan() {
> CalciteAssert.model(FoodmartSchema.FOODMART_MODEL)
> .query(" ( with a as (select * from \"sales_fact_1997\") select *
> from a)\n"
> + " union all\n"
> + " ( with b as (select * from \"sales_fact_1998\") select *
> from b)\n")
> .runs();
> }
> {code}
> will throw an {{AssertionError}} in {{SqlValidatorImpl.deduceModality}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5674) Cast expr to target type should respect nullable when it is complex type
[
https://issues.apache.org/jira/browse/CALCITE-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5674:
Labels: pull-request-available (was: )
> Cast expr to target type should respect nullable when it is complex type
>
>
> Key: CALCITE-5674
> URL: https://issues.apache.org/jira/browse/CALCITE-5674
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.35.0
>Reporter: jackylau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> {code:java}
> // code placeholder
>
> // code placeholder
> sql("select cast(array[1,null,2] as int array) from (values (1))")
> .columnType("INTEGER NOT NULL ARRAY NOT NULL");
> it is not correct, it should return INTEGER ARRAY NOT NULL {code}
>
> according the sql standard, cast to type, which can not be nulable and
> nullable is tabel level attribute which can not changed by cast.
> current the calcite cast will using nullable of expr to replace target type ,
> it is true. but it shoud also set array element type
> {code:java}
> // code placeholder
> /** Derives the type of "CAST(expression AS targetType)". */
> public static RelDataType deriveType(RelDataTypeFactory typeFactory,
> RelDataType expressionType, RelDataType targetType, boolean safe) {
> return typeFactory.createTypeWithNullability(targetType,
> expressionType.isNullable() || safe);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5688) Support TRUNCATE TABLE DDL statement in Babel parser
[ https://issues.apache.org/jira/browse/CALCITE-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5688: Labels: pull-request-available (was: ) > Support TRUNCATE TABLE DDL statement in Babel parser > > > Key: CALCITE-5688 > URL: https://issues.apache.org/jira/browse/CALCITE-5688 > Project: Calcite > Issue Type: Task > Components: babel, core >Reporter: Sumeet >Priority: Minor > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5401) Rule fired by HepPlanner can return Volcano's RelSubset
[
https://issues.apache.org/jira/browse/CALCITE-5401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5401:
Labels: pull-request-available (was: )
> Rule fired by HepPlanner can return Volcano's RelSubset
> ---
>
> Key: CALCITE-5401
> URL: https://issues.apache.org/jira/browse/CALCITE-5401
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ruben Q L
>Priority: Major
> Labels: pull-request-available
>
> TLDR; {{CoreRules.AGGREGATE_REMOVE}} is fired by a {{HepPlanner}} but while
> removing the Aggregate, instead of returning the Aggregate's input, it
> returns a VolcanoPlanner's RelSubset with the input, which leads to
> unforeseeable consequences.
>
> Details: This seems a strange issue that happens because several factors
> occur.
> I first reproduced it on my application with the following query (on TPCH):
> {code:sql}
> SELECT c.c_custkey
> FROM customer c
> WHERE c.c_name IN ('271', '272', '273', '274', '275', '276', '342', '343',
> '344', '345','346', '347', '348', '349', '350', '351', '352', '353', '354',
> '355', '356', '357', '358', '359', '360')
> AND EXISTS (SELECT 1 FROM orders o WHERE o.o_custkey = c.c_custkey)
> {code}
> But the issue can be reproduced also in Calcite by adding this test into
> {{{}HepPlannerTest{}}}:
> {code:java}
> @Test void testAggregateRemove() {
> final RelBuilder builder = RelBuilderTest.createBuilder(c ->
> c.withAggregateUnique(true));
> final RelNode root =
> builder
> .values(new String[]{"i"}, 1, 2, 3) // important to have values
> sorted
> .distinct()
> .build();
> final HepProgram program = new HepProgramBuilder()
> .addRuleInstance(CoreRules.AGGREGATE_REMOVE)
> .build();
> final HepPlanner planner = new HepPlanner(program);
> planner.setRoot(root);
> final RelNode result = planner.findBestExp();
> assertThat(result, is(instanceOf(LogicalValues.class))); // fails because
> result is a RelSubset
> }
> {code}
> The important elements are: firstly our {{RelOptCluster}} has a
> {{VolcanoPlanner}} as planner (so any {{relNode.getCluster().getPlanner()}}
> call that we execute will return a {{VolcanoPlanner}} instance). Nevertheless
> we also apply some rules via a {{{}HepPlanner{}}}. I think this is a quite
> common strategy in Calcite clients to obtain a better performance: first
> apply a subset of rules that are always beneficial via a {{{}HepPlanner{}}},
> and then apply the "main" set of rules via the cost-based
> {{{}VolcanoPlanner{}}}.
> Secondly, we have {{{}AggregateRemoveRule{}}}, which we use in the
> {{HepPlanner}} phase.
> This rule contains the following code:
> {code:java}
> @Override public void onMatch(RelOptRuleCall call) {
> final Aggregate aggregate = call.rel(0);
> final RelNode input = aggregate.getInput();
> ...
> final RelNode newInput = convert(input,
> aggregate.getTraitSet().simplify()); // <-- *** [1]
> relBuilder.push(newInput);
> ...
> call.getPlanner().prune(aggregate); // <-- *** [2]
> call.transformTo(relBuilder.build());
> }
> {code}
> Notice the line [2] which uses {{call.getPlanner()}} to call the {{prune}}
> method. By using {{call.getPlanner()}} we get the correct planner of the rule
> that is being fired, in this case a {{{}HepPlanner{}}}, so we end up calling
> {{{}HepPlanner#prune{}}}, which is fine.
> However, the line [1] calls the {{RelOptRule#convert}} static method:
> {code:java}
> public static RelNode convert(RelNode rel, RelTraitSet toTraits) {
> RelOptPlanner planner = rel.getCluster().getPlanner(); // <-- *** [3]
> RelTraitSet outTraits = rel.getTraitSet();
> for (int i = 0; i < toTraits.size(); i++) {
> RelTrait toTrait = toTraits.getTrait(i);
> if (toTrait != null)
> outTraits = outTraits.replace(i, toTrait);
> }
> if (rel.getTraitSet().matches(outTraits))
> return rel;
> return planner.changeTraits(rel, outTraits); // <-- *** [4]
> }
> {code}
> Notice how in this case, the planner is obtained from the relNode's cluster
> [3], in our case that would be the {{{}VolcanoPlanner{}}}, which is
> potentially problematic. Further down, if the relNode matches the
> {{{}outTraits{}}}, no action is done and the same relNode is returned, no
> problem here. But, if it does not match them, then
> {{RelOptPlanner#changeTraits}} will be called, i.e.
> {{VolcanoPlanner#changeTraits}} [4], and this is where the problem will
> originate: in our scenario {{VolcanoPlanner#changeTraits}} will return a
> Volcano's {{{}RelSubset{}}}, which is completely unhandable by the
> {{HepPlanner}} that triggered the rule, and that leads to the incorrect plan
> returned
[jira] [Updated] (CALCITE-3959) Implement INSTR function
[
https://issues.apache.org/jira/browse/CALCITE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3959:
Labels: pull-request-available (was: )
> Implement INSTR function
>
>
> Key: CALCITE-3959
> URL: https://issues.apache.org/jira/browse/CALCITE-3959
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Assignee: Joey Moore
>Priority: Major
> Labels: pull-request-available
>
> [BiqQuery|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#instr]
> and
> [Oracle|https://docs.oracle.com/cd/B13789_01/server.101/b10759/functions058.htm]
> both support functionally identical INSTR(source_value, search_value[,
> position[, occurrence]]) functions which accepts 2 (character strings or
> binary strings), 1 optional int representing position, and 1 optional int
> representing occurrence.
> Occurrence and position are assigned a default value of 1 if not specified.
> The function returns the 1-based position of the nth occurrence of the 2nd
> operand in the 1st operand where n is defined by the 4th operand. The
> function begins searching at the 1-based position specified in the 3rd
> operand.
> The function also supports negative position values, with -1 indicating the
> last character, and will search backwards from the position specified in that
> case.
> Returns 0 if:
> * No match is found.
> * If occurrence is greater than the number of matches found.
> * If position is greater than the length of source_value.
> Returns NULL if:
> * Any input argument is NULL.
> Returns an error if:
> * position is 0.
> * occurrence is 0 or negative.
> EXAMPLE: {{INSTR("abc", "bc")}} would return 2.
> EXAMPLE: {{INSTR("abcabc", "bc", 3)}} would return 5.
> EXAMPLE: {{INSTR("abcabc", "bc", -1, 1)}} would return 5.
> EXAMPLE: {{INSTR("abcabc", "bc", -1, 2)}} would return 2.
>
> MySQL also has an [INSTR|https://www.w3schools.com/sql/func_mysql_instr.asp]
> function, the functionality of which is a subset of the INSTR present in BQ
> and Oracle. MySQL INSTR only takes 2 parameters and returns the first
> occurrence of the search value in the source value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5547) Join using returns incorrect column names
[ https://issues.apache.org/jira/browse/CALCITE-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5547: Labels: pull-request-available (was: ) > Join using returns incorrect column names > - > > Key: CALCITE-5547 > URL: https://issues.apache.org/jira/browse/CALCITE-5547 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.33.0 >Reporter: Sean Broeder >Priority: Major > Labels: pull-request-available > > The query SELECT '' as \"xxx\", * > FROM (values (1, 4, 'one')) as t1(i ,j ,t ) > LEFT JOIN (values (1, -1)) as t2(i ,k ) > USING (i) > returns columns (xxx, i, j, i0), > but should return columns (xxx, i, j, t, k) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5679) HepPlanner#buildFinalplan: do not clear metadata cache if RelNode has not changed
[
https://issues.apache.org/jira/browse/CALCITE-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5679:
Labels: pull-request-available (was: )
> HepPlanner#buildFinalplan: do not clear metadata cache if RelNode has not
> changed
> -
>
> Key: CALCITE-5679
> URL: https://issues.apache.org/jira/browse/CALCITE-5679
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> Minor optimization:
> {{HepPlanner#buildFinalplan}} clears the metadata cache info of the impacted
> RelNode after replacing its inputs, but in the cases where the RelNode does
> not change (e.g. when it has no inputs) this clear cache should not be
> necessary (unless I'm missing something).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5676) Appropriately set `DATA_TYPE` and `TYPE_NAME` metadata values for `MEASURE` types
[
https://issues.apache.org/jira/browse/CALCITE-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5676:
Labels: pull-request-available (was: )
> Appropriately set `DATA_TYPE` and `TYPE_NAME` metadata values for `MEASURE`
> types
> -
>
> Key: CALCITE-5676
> URL: https://issues.apache.org/jira/browse/CALCITE-5676
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: TJ Banghart
>Assignee: TJ Banghart
>Priority: Minor
> Labels: pull-request-available
>
> Subtask of CALCITE-5549 to focus on the metadata we can control in
> calcite-core. Ensure that schema metadata and result set metadata agree on
> {{DATA_TYPE}} and {{TYPE_NAME}} for a {{MEASURE}}.
> The challenging part will be writing tests for this.
> [{{CalciteRemoteDriverTest.java}}|https://github.com/apache/calcite/blob/03050674594152ea785af69517f33960d7e27dd5/core/src/test/java/org/apache/calcite/jdbc/CalciteRemoteDriverTest.java#L99]
> has some that might be useful but use {{class Employee}} for a schema. We'll
> need a way to set some test {{MEASURE}} types as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5677) Fix unparsing for BigQuery SUBSTR
[
https://issues.apache.org/jira/browse/CALCITE-5677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5677:
Labels: pull-request-available (was: )
> Fix unparsing for BigQuery SUBSTR
> -
>
> Key: CALCITE-5677
> URL: https://issues.apache.org/jira/browse/CALCITE-5677
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> BigQuery's {{SUBSTR(value, position[, length])}} function currently gets
> translated to the standard {{SUBSTRING(value FROM position[ FOR length])]}.
> BigQuery expects the arguments to be comma-separated rather than the use of
> the {{FROM}} and {{FOR}} keywords.
> EXAMPLE: {{SUBSTR('hello', 2)}} would get translated to {{SUBSTRING('hello'
> FROM 2)}} which BigQuery does not recognize.
> Hive addresses this issue by adding onto {{HiveSqlDialect#unparseCall}}
> method. I believe BigQuery should do something similar to avoid this
> incorrect translation. The docs for the {{SUBSTR}} (and alias {{SUBSTRING}})
> function may be found
> [here|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#substr].
> I will open a PR shortly that implements my suggestion and adds a couple of
> tests as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5612) Babel parser should support PostgreSQL's SET TRANSACTION command
[
https://issues.apache.org/jira/browse/CALCITE-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5612:
Labels: pull-request-available (was: )
> Babel parser should support PostgreSQL's SET TRANSACTION command
>
>
> Key: CALCITE-5612
> URL: https://issues.apache.org/jira/browse/CALCITE-5612
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.34.0
>Reporter: Dmitry Sysolyatin
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Labels: pull-request-available
>
> SET TRANSACTION — set the characteristics of the current transaction
> Specification [1]:
> {code}
> SET TRANSACTION transaction_mode [, ...]
> SET TRANSACTION SNAPSHOT snapshot_id
> SET SESSION CHARACTERISTICS AS TRANSACTION transaction_mode [, ...]
> where transaction_mode is one of:
> ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ
> UNCOMMITTED }
> READ WRITE | READ ONLY
> [ NOT ] DEFERRABLE
> {code}
> [1] https://www.postgresql.org/docs/current/sql-set-transaction.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5675) Infer predicates for anti-join
[
https://issues.apache.org/jira/browse/CALCITE-5675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5675:
Labels: pull-request-available (was: )
> Infer predicates for anti-join
> --
>
> Key: CALCITE-5675
> URL: https://issues.apache.org/jira/browse/CALCITE-5675
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> Enhance {{RelMdPredicates}} to be able to infer predicates for anti-joins.
> Consider the following plans with an anti join between EMP and DEPT tables.
> +PulledUpPredicates+
> {noformat}
> LogicalJoin(condition=[=($7, $8)], joinType=[anti])
> LogicalFilter(condition=[=($1, 'Victor')])
> LogicalTableScan(table=[[scott, EMP]])
> LogicalFilter(condition=[=($1, 'CSD')])
> LogicalTableScan(table=[[scott, DEPT]])
> {noformat}
> We can infer that the {{>($1, 'Victor')}} predicate holds on the result of
> the join.
> +RightInferredPredicates+
> {noformat}
> LogicalJoin(condition=[=($7, $8)], joinType=[anti])
> LogicalFilter(condition=[>($7, 10)])
> LogicalTableScan(table=[[scott, EMP]])
> LogicalTableScan(table=[[scott, DEPT]])
> {noformat}
> We can infer that the {{>($0, 10)}} predicate holds on the right relation
> (DEPT).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5671) Add Option to Disable SSL Certificate Validation to ElasticSearch Adapter
[ https://issues.apache.org/jira/browse/CALCITE-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5671: Labels: pull-request-available (was: ) > Add Option to Disable SSL Certificate Validation to ElasticSearch Adapter > - > > Key: CALCITE-5671 > URL: https://issues.apache.org/jira/browse/CALCITE-5671 > Project: Calcite > Issue Type: New Feature > Components: elasticsearch-adapter >Affects Versions: 1.34.0 >Reporter: Charles Givre >Priority: Minor > Labels: pull-request-available > Fix For: 1.35.0 > > > For many development (and sometimes production) instances of ElasticSearch, > the instance is configured using a self-signed SSL certificate or otherwise > cannot be validated. > This PR adds a configuration option `disableSSLVerification` which, when set > to `true`, disables SSL verification. The default behavior is not changed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5670) Assertion error in SemiJoinJoinTransposeRule
[
https://issues.apache.org/jira/browse/CALCITE-5670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5670:
Labels: pull-request-available (was: )
> Assertion error in SemiJoinJoinTransposeRule
>
>
> Key: CALCITE-5670
> URL: https://issues.apache.org/jira/browse/CALCITE-5670
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.34.0
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> The following test will raise the assertion error:
> {code:java}
> @Test void testPushSemiJoinPastJoinRuleNotHappensJoinKeysDifferentOrigin() {
> // tests the case where the semijoin is pushed to the right
> final String sql = "select e.ename from emp e, dept d, bonus b\n"
> + "where e.deptno = d.deptno and e.ename = b.ename and d.name =
> b.job";
> sql(sql)
> .withRule(CoreRules.FILTER_INTO_JOIN,
> CoreRules.JOIN_ADD_REDUNDANT_SEMI_JOIN,
> CoreRules.SEMI_JOIN_JOIN_TRANSPOSE)
> .check();
> }
> {code}
> {noformat}
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.SemiJoinJoinTransposeRule.onMatch(SemiJoinJoinTransposeRule.java:112)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:337)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:556)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:420)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeRuleInstance(HepPlanner.java:243)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance$State.execute(HepInstruction.java:178)
> at
> org.apache.calcite.plan.hep.HepPlanner.lambda$executeProgram$0(HepPlanner.java:211)
> at
> com.google.common.collect.ImmutableList.forEach(ImmutableList.java:422)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:210)
> at
> org.apache.calcite.plan.hep.HepProgram$State.execute(HepProgram.java:118)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:205)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:191)
> at
> org.apache.calcite.test.RelOptFixture.checkPlanning(RelOptFixture.java:379)
> at org.apache.calcite.test.RelOptFixture.check(RelOptFixture.java:330)
> at org.apache.calcite.test.RelOptFixture.check(RelOptFixture.java:314)
> at
> org.apache.calcite.test.RelOptRulesTest.testPushSemiJoinPastJoinRuleNotHappensJoinKeysDifferentOrigin(RelOptRulesTest.java:2650)
> {noformat}
> The problem here is that the case when top-most Semi-Join has join keys from
> both tables of the bottom Join is considered impossible, though it happens in
> practice.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5664) Support CONVERT function with "USING" keyword
[
https://issues.apache.org/jira/browse/CALCITE-5664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5664:
Labels: pull-request-available (was: )
> Support CONVERT function with "USING" keyword
> -
>
> Key: CALCITE-5664
> URL: https://issues.apache.org/jira/browse/CALCITE-5664
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0
>Reporter: ZheHu
>Assignee: ZheHu
>Priority: Minor
> Labels: pull-request-available
>
> After CALCITE-111, we now support CONVERT(charValue, srcCharsetName,
> destCharsetName) that works on converting character sets.
> CONVERT(charValue USING transcodingName) also fits the SQL standard, and
> MySQL has implement it. For example:
> * select convert('employ_id' using utf16) as alia from employee
> Noted: Calcite already supports this from the parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5669) Remove trivial correlates from the query plan
[
https://issues.apache.org/jira/browse/CALCITE-5669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5669:
Labels: pull-request-available (was: )
> Remove trivial correlates from the query plan
> -
>
> Key: CALCITE-5669
> URL: https://issues.apache.org/jira/browse/CALCITE-5669
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> Consider the following query correlated query.
> {code:sql}
> select * from emp e where exists (select 1 from dept where empno=null)
> {code}
> The query basically returns an empty result cause {{empno=null}} is always
> false.
> The plan for the query after applying the sub-query remove rule is shown
> below:
> {noformat}
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}])
> LogicalProject(i=[true])
> LogicalFilter(condition=[=($cor0.EMPNO, null)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {noformat}
> After applying the reduce expressions rule the filter with the correlated
> condition will become false and the resulting plan would be the following.
> {noformat}
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}])
> LogicalProject(i=[true])
> LogicalValues(tuples=[[]])
> {noformat}
> Observe that now we have a {{LogicalCorrelate}} but there is no real
> correlation in the plan since the correlation variable on the right side
> disappeared. Depending on how rules are applied and which rules are used
> similar "trivial" correlates may appear.
> The goal of this ticket is to provide the means to get rid of them.
> One option would be to add a new rule (e.g., {{CorrelateToJoinRule}}) which
> detects that a correlate does not have correlations in the right side and
> turn the correlation to a join; then we could employ other existing rules
> (such as PruneEmptyRules) for joins and remove the newly created join
> altogether.
> Another option, would be to introduce new pruning rule(s) for correlate
> (similar to those for joins) that will remove the correlate when its input is
> an empty values expression.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5665) Reducing ineffective matches for MaterializedViewRules and double calculation for RelOptMaterialization's Metadata using cache
[ https://issues.apache.org/jira/browse/CALCITE-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5665: Labels: pull-request-available (was: ) > Reducing ineffective matches for MaterializedViewRules and double calculation > for RelOptMaterialization's Metadata using cache > -- > > Key: CALCITE-5665 > URL: https://issues.apache.org/jira/browse/CALCITE-5665 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: asdfgh19 >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > MaterializedViewRule such as MaterializedViewOnlyFilterRule and > MaterializedViewOnlyJoinRule are easy to match, which results in multiple > executions of the MaterializedViewRule#perform method, most of which are > ineffective. Each execution of this method requires traversing the query > relational expression tree and the materialized view relational expression > tree multiple times. > For example, the > MaterializedViewRelOptRulesTest#testJoinAggregateMaterializationNoAggregateFuncs9 > method will execute this method 489 times. > There are many cases where we can pre-filter out invalid matches. For > example, all materialized views are Aggregate MV and the current rule is > MaterializedViewOnlyJoinRule. > We can also cache RelOptMaterialization Metadata to reduce repeated > calculations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5662) CAST(BOOLEAN as INTEGER) throws a NumberFormatException
[
https://issues.apache.org/jira/browse/CALCITE-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5662:
Labels: pull-request-available (was: )
> CAST(BOOLEAN as INTEGER) throws a NumberFormatException
> ---
>
> Key: CALCITE-5662
> URL: https://issues.apache.org/jira/browse/CALCITE-5662
> Project: Calcite
> Issue Type: Bug
>Reporter: Oliver Lee
>Assignee: Oliver Lee
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently attempting to run {{SELECT CAST(BOOLEAN as INTEGER)}} will throw a
> {{NumberFormatException}}.
> The BigQuery dialect allows casting {{boolean}} to the following:
> {{string}}, {{int64}} , {{tinyint}}, {{smallint}}, {{bigint}}
> src:
> https://cloud.google.com/bigquery/docs/reference/standard-sql/conversion_functions
>
> Desired behavior:
> {{SELECT CAST(TRUE as INTEGER)}} -> {{1}}
> {{SELECT CAST(TRUE as BIGINT)}} -> {{1}}
> {{SELECT CAST(FALSE as INTEGER)}} -> {{0}}
> {{SELECT CAST(null as INTEGER)}} -> {{null}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5660) Implement BigQuery Array Subscript Operators
[
https://issues.apache.org/jira/browse/CALCITE-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5660:
Labels: pull-request-available (was: )
> Implement BigQuery Array Subscript Operators
>
>
> Key: CALCITE-5660
> URL: https://issues.apache.org/jira/browse/CALCITE-5660
> Project: Calcite
> Issue Type: Task
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When indexing an array in BigQuery, you are required to wrap the index in one
> of four position keywords: {{OFFSET}}, {{ORDINAL}}, {{SAFE_OFFSET}}, and
> {{SAFE_ORDINAL}}.
> {{OFFSET(index)}}: The index starts at zero. Produces an error if the index
> is out of range.
> {{SAFE_OFFSET(index)}}: The index starts at zero. Returns NULL if the index
> is out of range.
> {{ORDINAL(index)}}: The index starts at one. Produces an error if the index
> is out of range.
> {{SAFE_ORDINAL(index)}}: The index starts at one. Returns NULL if the index
> is out of range.
> These operators are very similar to the existing {{ITEM}} operator currently
> used to index an array in Calcite. I believe the offset and out of bounds
> behavior for the existing implementation could be parameterized to support
> the above operators.
> [Link to BigQuery
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/operators#array_subscript_operator]
> I will have a PR open for this in the next day or two, in the meantime any
> comments, questions, or suggestions are welcome as always.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5656) RelToSqlConverter has an error using ordinal for ORDER BY
[
https://issues.apache.org/jira/browse/CALCITE-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5656:
Labels: pull-request-available (was: )
> RelToSqlConverter has an error using ordinal for ORDER BY
> -
>
> Key: CALCITE-5656
> URL: https://issues.apache.org/jira/browse/CALCITE-5656
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: luoping.zhang
>Assignee: luoping.zhang
>Priority: Critical
> Labels: pull-request-available
> Attachments: image-2023-04-18-16-29-44-899.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example:
> Query SQL is
> {code:java}
> select a from table order by coalesce(a,b){code}
> When we convert this sql to relNode and convert it back to SQL by
> RelToConverter, the result is:
> {code:java}
> select a from table order by 2{code}
> But this sql syntax is wrong because there is no ordinal 2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5402) RelToSql generates invalid code if left and right side field names clash
[
https://issues.apache.org/jira/browse/CALCITE-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5402:
Labels: pull-request-available (was: )
> RelToSql generates invalid code if left and right side field names clash
>
>
> Key: CALCITE-5402
> URL: https://issues.apache.org/jira/browse/CALCITE-5402
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.32.0
>Reporter: Leonid Chistov
>Assignee: Leonid Chistov
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Wrong SQL code is generated when left and right side of a semi-join have
> fields with same name.
> Generated condition looks like `FIELD` = `rhs table`.`FIELD`, where left
> `FIELD` is resolved to be the same as `rhs table`.`FIELD` during query
> execution, but not a reference to an outer table of correlated subquery, as
> was intended.
> Examples of tests that would fail if added to RelToSqlConverterTest.java:
> {code:java}
> @Test void testSemiJoinNameClash() {
> final RelBuilder builder = relBuilder();
> final RelNode root = builder
> .scan("DEPT")
> .project(builder.field("DEPTNO"), builder.field("DNAME"))
> .scan("EMP")
> .filter(
> builder.call(SqlStdOperatorTable.GREATER_THAN,
> builder.field("JOB"),
> builder.literal((short) 10)))
> .project(builder.field("DEPTNO"))
> .join(
> JoinRelType.SEMI, builder.equals(
> builder.field(2, 0, "DEPTNO"),
> builder.field(2, 1, "DEPTNO")))
> .project(builder.field("DEPTNO"))
> .build();
> final String expectedSql = "SELECT \"DEPTNO\"\n"
> + "FROM (SELECT \"DEPTNO\", \"EMPNO\"\n"
> + "FROM \"scott\".\"DEPT\"\n"
> + "WHERE EXISTS (SELECT 1\n"
> + "FROM (SELECT \"EMPNO\"\n"
> + "FROM \"scott\".\"EMP\"\n"
> + "WHERE \"JOB\" > 10) AS \"t1\"\n"
> + "WHERE \"DEPT\".\"EMPNO\" = \"t1\".\"EMPNO\")) AS \"t\"";
> assertThat(toSql(root), isLinux(expectedSql));
> } {code}
>
> {code:java}
> @Test void testSemiJoinWithSameTable() {
> final RelBuilder builder = relBuilder();
> final RelNode root = builder
> .scan("EMP")
> .project(builder.field("DEPTNO"), builder.field("EMPNO"))
> .scan("EMP")
> .filter(
> builder.call(SqlStdOperatorTable.GREATER_THAN,
> builder.field("JOB"),
> builder.literal((short) 10)))
> .project(builder.field("EMPNO"))
> .join(
> JoinRelType.SEMI, builder.equals(
> builder.field(2, 0, "EMPNO"),
> builder.field(2, 1, "EMPNO")))
> .project(builder.field("DEPTNO"))
> .build();
> final String expectedSql = "SELECT \"DEPTNO\"\n"
> + "FROM (SELECT \"DEPTNO\", \"EMPNO\"\n"
> + "FROM \"scott\".\"EMP\"\n"
> + "WHERE EXISTS (SELECT 1\n"
> + "FROM (SELECT \"EMPNO\"\n"
> + "FROM \"scott\".\"EMP\"\n"
> + "WHERE \"JOB\" > 10) AS \"t1\"\n"
> + "WHERE \"EMP\".\"EMPNO\" = \"t1\".\"EMPNO\")) AS \"t\"";
> assertThat(toSql(root), isLinux(expectedSql));
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5659) Allow CAST in an INTERVAL definition
[
https://issues.apache.org/jira/browse/CALCITE-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5659:
Labels: pull-request-available (was: )
> Allow CAST in an INTERVAL definition
> -
>
> Key: CALCITE-5659
> URL: https://issues.apache.org/jira/browse/CALCITE-5659
> Project: Calcite
> Issue Type: Bug
>Reporter: Oliver Lee
>Assignee: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Running queries that contain a CAST as part of the INTERVAL definition is
> throwing a parser error.
> i.e.
> {{INTERVAL CAST(5 as int64) YEAR}}
> We can make parser changes to allow the Cast function tokens to be accepted
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5657) Add ARRAY_DISTINCT for Spark dialect
[
https://issues.apache.org/jira/browse/CALCITE-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5657:
Labels: pull-request-available (was: )
> Add ARRAY_DISTINCT for Spark dialect
>
>
> Key: CALCITE-5657
> URL: https://issues.apache.org/jira/browse/CALCITE-5657
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0
>Reporter: jackylau
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ARRAY_DISTINCT}} - Returns the input ARRAY with unique elements. If the
> array itself is null, the function will return null. Keeps ordering of
> elements.
> For more details
> https://spark.apache.org/docs/latest/sql-ref-functions-builtin.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5653) expended casts are missing when IdentifierExpansion is false
[
https://issues.apache.org/jira/browse/CALCITE-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5653:
Labels: pull-request-available (was: )
> expended casts are missing when IdentifierExpansion is false
>
>
> Key: CALCITE-5653
> URL: https://issues.apache.org/jira/browse/CALCITE-5653
> Project: Calcite
> Issue Type: Bug
>Reporter: Itiel Sadeh
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When casts are added in {{{}SqlValidator{}}}, they are not part of the select
> if the configuration option {{identifierExpansion}} is false. This will cause
> the following issue
> {code:java}
> SELECT distinct sum(deptno + '1') FROM dept ORDER BY 1
> {code}
> will lead to:
> {code:java}
> From line 1, column 21 to line 1, column 54: Expression 'SUM(`DEPT`.`DEPTNO`
> + CAST('1' AS INTEGER))' is not in the select clause
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 21 to
> line 1, column 54: Expression 'SUM(`DEPT`.`DEPTNO` + CAST('1' AS INTEGER))'
> is not in the select clause
> at
> java.base@17.0.5/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base@17.0.5/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> java.base@17.0.5/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base@17.0.5/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at
> java.base@17.0.5/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
> at
> app//org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
> at
> app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:945)
> at
> app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:930)
> at
> app//org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5464)
> at
> app//org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:168)
> at
> app//org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:45)
> at app//org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> app//org.apache.calcite.sql.validate.AggregatingSelectScope.checkAggregateExpr(AggregatingSelectScope.java:233)
> at
> app//org.apache.calcite.sql.validate.AggregatingSelectScope.validateExpr(AggregatingSelectScope.java:242)
> at
> app//org.apache.calcite.sql.validate.OrderByScope.validateExpr(OrderByScope.java:128)
> at
> app//org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4676)
> at
> app//org.apache.calcite.sql.validate.SqlValidatorImpl.validateOrderItem(SqlValidatorImpl.java:4398)
> at
> app//org.apache.calcite.sql.validate.SqlValidatorImpl.validateOrderList(SqlValidatorImpl.java:4341)
> at
> app//org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3786)
> at
> app//org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:61)
> at
> app//org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> app//org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1135)
> at
> app//org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1106)
> at app//org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:282)
> at
> app//org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1081)
> at
> app//org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:787)
> {code}
> The issue is that the code in{{ AggChecker}} will search for the expanded
> node (with the CAST) in the select list, but the select list contains only
> the unexpanded node.
> This can be solved through setting{{ identifierExpansion }}to true, but I
> don't think it should be related, as it's not an identifier expansion here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5655) Wrong plan for multiple IN/SOME sub-queries with OR predicate
[
https://issues.apache.org/jira/browse/CALCITE-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5655:
Labels: pull-request-available (was: )
> Wrong plan for multiple IN/SOME sub-queries with OR predicate
> -
>
> Key: CALCITE-5655
> URL: https://issues.apache.org/jira/browse/CALCITE-5655
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Runkang He
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When the query contains multiple IN/SOME sub-queries connected with OR
> predicate in WHERE clause, the result is wrong. The minimal reproducer is
> below:
> SQL:
> {code:sql}
> select empno from sales.empnullables
> where deptno in (
> select deptno from sales.deptnullables where name = 'dept1')
> or deptno in (
> select deptno from sales.deptnullables where name = 'dept2')
> {code}
> The Plan generated by calcite master branch: (Notice the bold part of *<>($2,
> 0)* in the downstream LogicalFilter)
> {code:sql}
> LogicalProject(EMPNO=[$0])
> LogicalProject(EMPNO=[$0], DEPTNO=[$1])
> LogicalFilter(condition=[OR(AND(<>($2, 0), IS NOT NULL($5), IS NOT
> NULL($1)), AND(***<>($2, 0)***, IS NOT NULL($9), IS NOT NULL($1)))])
> LogicalJoin(condition=[=($1, $8)], joinType=[left])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalJoin(condition=[=($1, $4)], joinType=[left])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalTableScan(table=[[CATALOG, SALES, EMPNULLABLES]])
> LogicalAggregate(group=[{}], c=[COUNT()], ck=[COUNT($0)])
> LogicalProject(DEPTNO=[$0])
> LogicalFilter(condition=[=($1, 'dept1')])
> LogicalTableScan(table=[[CATALOG, SALES, DEPTNULLABLES]])
> LogicalProject(DEPTNO=[$0], i=[true])
> LogicalFilter(condition=[=($1, 'dept1')])
> LogicalTableScan(table=[[CATALOG, SALES, DEPTNULLABLES]])
> LogicalAggregate(group=[{}], c=[COUNT()], ck=[COUNT($0)])
> LogicalProject(DEPTNO=[$0])
> LogicalFilter(condition=[=($1, 'dept2')])
> LogicalTableScan(table=[[CATALOG, SALES, DEPTNULLABLES]])
> LogicalProject(DEPTNO=[$0], i=[true])
> LogicalFilter(condition=[=($1, 'dept2')])
> LogicalTableScan(table=[[CATALOG, SALES, DEPTNULLABLES]])
> {code}
> The wrong part is that when build the downstream LogicalFilter for the two
> sub-queries, the filter for the second sub-query is AND(<>($2, 0), IS NOT
> NULL($9), IS NOT NULL($1)), notice that *$2 should be the second sub-query's
> intermediate table field ct.c(which field index is $6), but now the actual
> reference is the first sub-query's*, this leads to wrong plan, and wrong
> result.
> The root cause is that intermediate table alias is the same as the previous
> sub-query's, but when lookup intermediate table field, it always returns the
> previous one which is not belong to the current subquery.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5654) Support PostgreSQL's syntax for day-to-second intervals
[ https://issues.apache.org/jira/browse/CALCITE-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5654: Labels: pull-request-available (was: ) > Support PostgreSQL's syntax for day-to-second intervals > --- > > Key: CALCITE-5654 > URL: https://issues.apache.org/jira/browse/CALCITE-5654 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Tim Nieradzik >Assignee: Tim Nieradzik >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Support day-to-second intervals using PostgreSQL's syntax: > select INTERVAL '2 weeks 3 days 4 hours 5 minutes 6 seconds 7 milliseconds' > select INTERVAL '-30 day' > These should be equivalent to: > select INTERVAL '17 04:05:06.007' DAY TO SECOND > select -INTERVAL '30 00:00:00.000' DAY TO SECOND -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5651) Type system decimal scale in inferred types may exceed allowed scale
[
https://issues.apache.org/jira/browse/CALCITE-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5651:
Labels: pull-request-available (was: )
> Type system decimal scale in inferred types may exceed allowed scale
>
>
> Key: CALCITE-5651
> URL: https://issues.apache.org/jira/browse/CALCITE-5651
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If one uses a type system with a scale which is < precision/2 the calcite
> compiler may crash with an assertion failure. This can happen in the
> RelDataTypeSystem.deriveDecimalPlusType method, where this assertion fails:
> assert scale <= getMaxNumericScale();
> The root cause is the function SqlTypeUtil.getMaxPrecisionScaleDecimal, which
> does the following:
> int scale = maxPrecision / 2;
> This was introduced in Calcite 1.27.
> I think the a better version should be
> int scale = Math.min(maxPrecision/2,
> factory.getTypeSystem().getMaxNumericScale());
> To reproduce this bug I had to do a bit of juggling. First I had to fix the
> bug reported in Calcite-5650. Then I added the following two functions in
> RelToSqlConverterTest.java:
> @Test void testNumericScale() {
> String q = "WITH v(x) AS (VALUES('4.2')) " +
> " SELECT x1 + x2 FROM v AS v1(x1), v AS V2(x2)";
> sql(q)
> .withPostgresqlModifiedDecimalTypeSystem()
> .ok("");
> }
> and in the static class Sql I added this method:
> Sql withPostgresqlModifiedDecimalTypeSystem() {
> final PostgresqlSqlDialect postgresqlSqlDialect =
> new PostgresqlSqlDialect(PostgresqlSqlDialect.DEFAULT_CONTEXT
> .withDataTypeSystem(new RelDataTypeSystemImpl() {
> @Override
> public int getMaxNumericScale() {
> return 10;
> }
> @Override
> public int getMaxNumericPrecision() {
> return 39;
> }
> }));
> return dialect(postgresqlSqlDialect);
> }
> This is the exception stack trace:
> java.lang.AssertionError
> at
> org.apache.calcite.rel.type.RelDataTypeSystem.deriveDecimalPlusType(RelDataTypeSystem.java:167)
> at
> org.apache.calcite.sql.type.ReturnTypes.lambda$static$8(ReturnTypes.java:653)
> at
> org.apache.calcite.sql.type.SqlTypeTransformCascade.inferReturnType(SqlTypeTransformCascade.java:58)
> at
> org.apache.calcite.sql.type.SqlReturnTypeInferenceChain.inferReturnType(SqlReturnTypeInferenceChain.java:55)
> at
> org.apache.calcite.sql.SqlOperator.inferReturnType(SqlOperator.java:537)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:504)
> at org.apache.calcite.sql.SqlOperator.deriveType(SqlOperator.java:605)
> at
> org.apache.calcite.sql.SqlBinaryOperator.deriveType(SqlBinaryOperator.java:178)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6521)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6508)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1897)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1882)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:489)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4608)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3780)
> 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:1135)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1106)
> at
> org.apache.calcite.sql.validate.WithNamespace.validateImpl(WithNamespace.java:59)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1135)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWith(SqlValidatorImpl.java:4240)
> at org.apache.calcite.sql.SqlWith.validate(SqlWith.java:74)
> at
>
[jira] [Updated] (CALCITE-5650) Sql.dialect method in RelToSqlConverterTests ignores dialect type system
[
https://issues.apache.org/jira/browse/CALCITE-5650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5650:
Labels: pull-request-available (was: )
> Sql.dialect method in RelToSqlConverterTests ignores dialect type system
>
>
> Key: CALCITE-5650
> URL: https://issues.apache.org/jira/browse/CALCITE-5650
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The problem is in the file SqlToRelConverterTest.java, in the static class
> Sql, in the following method:
> Sql dialect(SqlDialect dialect) {
> return new Sql(schemaSpec, sql, dialect, parserConfig, librarySet,
> config,
> relFn, transforms, typeSystem);
> }
> The problem is that the dialect may have a different type system, which is
> ignored in this function. I think the function should read:
> Sql dialect(SqlDialect dialect) {
> return new Sql(schemaSpec, sql, dialect, parserConfig, librarySet,
> config,
> relFn, transforms, dialect.getTypeSystem());
> }
> Several tests in this file do change the dialect type system.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5649) Produce row count statistics from ReflectiveSchema for array based tables
[
https://issues.apache.org/jira/browse/CALCITE-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5649:
Labels: pull-request-available (was: )
> Produce row count statistics from ReflectiveSchema for array based tables
> -
>
> Key: CALCITE-5649
> URL: https://issues.apache.org/jira/browse/CALCITE-5649
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0
>Reporter: Adam Kennedy
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When testing new Calcite implementations it is easy to use (and several
> online examples indeed use) a trivial reflected synthetic schema such as the
> following:
> {code:java}
> public Schema getSchema() {
> return new ReflectiveSchema(new PeopleSchema());
> }
> public static final class PeopleSchema {
> public final Person[] heroes = {
> new Person("Ironman", 12),
> new Person("Batman", 10)
> };
> public static class Person {
> public final String name;
> public final int age;
> public Person(final String name, final int age) {
> this.name = name;
> this.age = age;
> }
> }
> }
> {code}
> While this works for some basics, the lack of statistics makes it less useful
> than it could be. While not all variations supported by ReflectiveSchema can
> easily capture statistics, the variation which provides the table as an array
> has trivial access to a valid RowCount value.
> For these simple cases ReflectiveSchema should provide a Statistic object
> with a valid row count so the simple synthetic schemas will be more useful.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5648) SqlDelegatingConformance incorrectly delegates to SqlConformanceEnum.DEFAULT
[ https://issues.apache.org/jira/browse/CALCITE-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5648: Labels: pull-request-available (was: ) > SqlDelegatingConformance incorrectly delegates to SqlConformanceEnum.DEFAULT > > > Key: CALCITE-5648 > URL: https://issues.apache.org/jira/browse/CALCITE-5648 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Adam Kennedy >Priority: Major > Labels: pull-request-available > Original Estimate: 1h > Time Spent: 10m > Remaining Estimate: 50m > > SqlDelegatingConformance is implemented as a sub-class of > SqlAbstractConformance instead of being a pure delegator and just implemented > the SqlConformance interface. > Because of this when a new method is added to the SqlConformance interface > (as happens fairly regularly) no exception or missing method compile error > will be triggered for SqlDelegatingConformance and there is no indication > that the class will misbehave. > Instead what will happen is that for the newly added methods, calls to an > instance of SqlDelegatingConformance will be send to the > SqlAbstractConformance version of the method instead of the delegate's > version of the method, silently returning the incorrect value any time the > delegate has a different behavior than SqlConformanceEnum.DEFAULT. > SqlDelegatingConformance should be changed to directly implement the > interface, which will force a new delegating method to be added any time a > new method is added to the SqlConformance interface by just failing to > compile. On compilation failure, the fix of added a new delegating method is > obvious. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5647) RelMdPopulationSize calls rel.estimateRowCount instead of mq.getRowCount
[ https://issues.apache.org/jira/browse/CALCITE-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5647: Labels: pull-request-available (was: ) > RelMdPopulationSize calls rel.estimateRowCount instead of mq.getRowCount > > > Key: CALCITE-5647 > URL: https://issues.apache.org/jira/browse/CALCITE-5647 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Adam Kennedy >Priority: Minor > Labels: pull-request-available > Original Estimate: 1h > Time Spent: 10m > Remaining Estimate: 50m > > A few locations in Calcite call rel.estimateRowCount(mq) when they should > instead call mq.getRowCount(red). > We detected this because we implemented row count estimation entirely within > an alternative handle instead of RelMdRowCount, and then override > estimateRowCount to ensure the custom handler is user, by throwing an > unreachable code exception. > A few places in Calcite trigger these unreachable exceptions because they do > not use mq.getRowCount. > The most easily triggered on is in RelMdPopulationSize for the Values > parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5014) PartiallyOrderedSet definition of antisymmetric is incorrect
[ https://issues.apache.org/jira/browse/CALCITE-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5014: Labels: pull-request-available (was: ) > PartiallyOrderedSet definition of antisymmetric is incorrect > > > Key: CALCITE-5014 > URL: https://issues.apache.org/jira/browse/CALCITE-5014 > Project: Calcite > Issue Type: Bug >Reporter: Innovimax Moz >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > in [PartiallyOrderedSet (Apache Calcite > API)|https://calcite.apache.org/javadocAggregate/org/apache/calcite/util/PartiallyOrderedSet.html] > > we can read > * anti-symmetric: if e.lte(f) returns true, then f.lte(e) returns > +_*false*_+ only if e = f; > > instead we should read > * anti-symmetric: if e.lte(f) returns true, then f.lte(e) returns *_+true+_* > only if e = f; > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5642) Add SHA256, SHA512 functions
[ https://issues.apache.org/jira/browse/CALCITE-5642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5642: Labels: pull-request-available (was: ) > Add SHA256, SHA512 functions > > > Key: CALCITE-5642 > URL: https://issues.apache.org/jira/browse/CALCITE-5642 > Project: Calcite > Issue Type: New Feature >Reporter: Dan Zou >Assignee: Dan Zou >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Add SHA256, SHA512 functions and enable them for BigQuery. > SHA256: Computes the hash of the input using the [SHA-256 > algorithm|https://en.wikipedia.org/wiki/SHA-2]. This function returns 32 > bytes. > SHA512: Computes the hash of the input using the [SHA-512 > algorithm|https://en.wikipedia.org/wiki/SHA-2]. This function returns 64 > bytes. > See more details in [BigQuery > Doc|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#sha256] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5644) Implement BigQuery CONTAINS_SUBSTR
[
https://issues.apache.org/jira/browse/CALCITE-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5644:
Labels: pull-request-available (was: )
> Implement BigQuery CONTAINS_SUBSTR
> --
>
> Key: CALCITE-5644
> URL: https://issues.apache.org/jira/browse/CALCITE-5644
> Project: Calcite
> Issue Type: Task
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> BigQuery offers the
> [CONTAINS_SUBSTR|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#contains_substr]
> function that returns {{TRUE}} if a substring is present in an expression
> and {{FALSE}} if it is not. A basic example of this may be seen in [1].
> The expression can take many forms (more info in the linked doc) which makes
> its implementation more complex than other string functions that only accept
> arguments of type {{STRING}}. For instance, the expression to be searched can
> be a column or table reference.
> The function also has an optional third argument called {{json_scope}} where
> the user can indicate the scope of JSON data (keys, values, or both) to be
> searched for the substring.
> I am curious if anyone has thoughts on how the search of rows or tables
> could be implemented. I have a basic implementation (that supports
> expressions of type {{STRING}} and nothing else) that I will open a draft PR
> for as a starting point. To me, the challenge is implementing the additional
> features like the {{JSON_SCOPE}} argument (seen in [2]) and performing a
> cross field search as seen in [3].
> [1] {{SELECT CONTAINS_SUBSTR("hello", "he");}} would return {{TRUE}}.
> [2] SELECT CONTAINS_SUBSTR(JSON '("lunch":"soup")', "lunch",
> json_scope=>"JSON_VALUES") AS result;
> would return {{FALSE}}.
> [3]
> {{SELECT *
> FROM Recipes
> WHERE CONTAINS_SUBSTR(
> (SELECT AS STRUCT Recipes.* EXCEPT (Lunch, Dinner)),
> 'potato'
> );}} would return:
> ||Breakfast||Lunch||Dinner||
> |Potato pancakes|Toasted cheese sandwich|Beef stroganoff|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5636) Consult type mappings when coercing types.
[
https://issues.apache.org/jira/browse/CALCITE-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5636:
Labels: pull-request-available (was: )
> Consult type mappings when coercing types.
> --
>
> Key: CALCITE-5636
> URL: https://issues.apache.org/jira/browse/CALCITE-5636
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Will Noble
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is another offshoot of CALCITE-5346.
> In
> [{{AbstractTypeCoercion.implicitCast}}|https://github.com/apache/calcite/blob/2dba40e7a0a5651eac5a30d9e0a72f178bd9bff2/core/src/main/java/org/apache/calcite/sql/validate/implicit/AbstractTypeCoercion.java#L713],
> Calcite may insert {{CAST}} invocations disregarding the root schema type
> map. This happens during the validation phase, so it's easy enough to read
> the type map directly in the {{AbstractTypeCoercion}} utility, although it's
> hard to say if this is an optimal solution. It may make sense to incorporate
> the type map into the {{RelDataTypeSystem}} which is more widely available in
> non-validation phases of SQL processing pipelines.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5634) Add LEAST, GREATEST for PostgreSQL
[ https://issues.apache.org/jira/browse/CALCITE-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5634: Labels: pull-request-available (was: ) > Add LEAST, GREATEST for PostgreSQL > -- > > Key: CALCITE-5634 > URL: https://issues.apache.org/jira/browse/CALCITE-5634 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Dmitry Sysolyatin >Assignee: Dmitry Sysolyatin >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The LEAST and GREATEST functions have been implemented for BigQuery and > Oracle, but haven't been added for PostgreSQL. PostgreSQL supports LEAST, > GREATEST as well [1] > [1] > https://www.postgresql.org/docs/15/functions-conditional.html#FUNCTIONS-GREATEST-LEAST -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5614) Serialize and deserialize Sarg objects
[
https://issues.apache.org/jira/browse/CALCITE-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5614:
Labels: pull-request-available (was: )
> Serialize and deserialize Sarg objects
> --
>
> Key: CALCITE-5614
> URL: https://issues.apache.org/jira/browse/CALCITE-5614
> Project: Calcite
> Issue Type: Improvement
>Reporter: Oliver Lee
>Assignee: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Context: Bounded filter conditions (e.g. {{{}SUM(field> > 1 AND SUM(field) <
> 10{}}}) are converted to calls to a [SEARCH
> operator.|https://github.com/apache/calcite/blob/052a5cc724a889edf19c1d76ea166c0d0924a5d3/core/src/main/java/org/apache/calcite/rex/RexInterpreter.java#L224calls]
> If this is then serialized and deserialized, it will throw an exception when
> resolving {{{}SEARCH{}}}.
>
>
> To complete this ticket: Add functionality such that {{Sarg}} literals can be
> serialized and deserialized.
>
> {{RelJson.java}} should be updated so that {{toRex}} can serialize {{Sarg}}
> objects
>
> {{RexBuilder.java}} should be updated to be able to successfully deserialize
> a JSON string that includes {{Sarg}} literals
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5628) Cannot parse map function for Spark Dialect
[
https://issues.apache.org/jira/browse/CALCITE-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5628:
Labels: pull-request-available (was: )
> Cannot parse map function for Spark Dialect
> ---
>
> Key: CALCITE-5628
> URL: https://issues.apache.org/jira/browse/CALCITE-5628
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Guillaume Massé
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Similar to CALCITE-5624
>
> AtomicRowExpression should not have MapConstructor for Apache Spark. Maps are
> constructed by calling the map function
> (https://spark.apache.org/docs/latest/api/sql/index.html#map).
>
> {code:java}
> map()
> map(1.0, '2', 3.0, '4');{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5624) Cannot parse array function for Spark Dialect
[ https://issues.apache.org/jira/browse/CALCITE-5624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5624: Labels: pull-request-available (was: ) > Cannot parse array function for Spark Dialect > - > > Key: CALCITE-5624 > URL: https://issues.apache.org/jira/browse/CALCITE-5624 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Guillaume Massé >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > AtomicRowExpression should not have ArrayConstructor for Apache Spark. Arrays > are constructed by calling the array function > ([https://spark.apache.org/docs/latest/api/sql/index.html#array]). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-4771) change the value of the CAST function to be nullable
[
https://issues.apache.org/jira/browse/CALCITE-4771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4771:
Labels: pull-request-available (was: )
> change the value of the CAST function to be nullable
> -
>
> Key: CALCITE-4771
> URL: https://issues.apache.org/jira/browse/CALCITE-4771
> Project: Calcite
> Issue Type: Improvement
>Reporter: xuyang
>Assignee: Dan Zou
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-09-16-11-43-55-743.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the sql "SELECT CAST('haha' AS INT)",the value the function CAST returns
> will be parsed into NOT NULL, because when parsing, the type CAST returns is
> from the INT and the nullable attribute is from the 'haha', which doesn't
> consider the condition that parsing a string to an int could be invalid and
> return NULL values.
> I think there are two ways to improve this question:
> * One is to change the value of the CAST function to be nullable, which
> avoids the invalid parsing.
> * The other way is to introduce a function named TRY_CAST, which is used in
> SQL Server.If the parsing fails, TRY_CAST will return NULL instead of throws
> exception that a NOT NULL field will be set with our unexpected value NULL.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5621) Support UDT declarations from root of JSON schema model
[
https://issues.apache.org/jira/browse/CALCITE-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5621:
Labels: pull-request-available (was: )
> Support UDT declarations from root of JSON schema model
> ---
>
> Key: CALCITE-5621
> URL: https://issues.apache.org/jira/browse/CALCITE-5621
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: TJ Banghart
>Assignee: TJ Banghart
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Related to CALCITE-5346.
> This change would allow for declaring user-defined types at the root of a
> schema model and allows for easy type alias mapping.
> These data types are shared by all schema in the model so cast and DDL
> expressions do not need to scope data type references to a particular
> sub-schema.
> For example:
> {code}
> ...
> "inline":{
> "version":"1.0",
> "types":[
> {
> "name":"BOOL",
> "type":"BOOLEAN"
> },
> {
> "name":"BYTES",
> "type":"VARBINARY"
> }
> ]
> ...
> {code}
> Would allow for {{CAST("true" as BOOL)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5619) Support PostgreSQL's TO_CHAR function
[ https://issues.apache.org/jira/browse/CALCITE-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5619: Labels: pull-request-available (was: ) > Support PostgreSQL's TO_CHAR function > - > > Key: CALCITE-5619 > URL: https://issues.apache.org/jira/browse/CALCITE-5619 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Tim Nieradzik >Assignee: Tim Nieradzik >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The following query cannot be parsed because `to_char` is not supported: > `select to_char(current_timestamp, '-MM-DD HH24:MI:SS.MS TZ')` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5543) Implement BigQuery functions for parsing DATE, TIME, TIMESTAMP, DATETIME
[ https://issues.apache.org/jira/browse/CALCITE-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5543: Labels: pull-request-available (was: ) > Implement BigQuery functions for parsing DATE, TIME, TIMESTAMP, DATETIME > > > Key: CALCITE-5543 > URL: https://issues.apache.org/jira/browse/CALCITE-5543 > Project: Calcite > Issue Type: Wish >Reporter: Marieke Gueye >Assignee: TJ Banghart >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Implement PARSE_DATE, PARSE_DATETIME, PARSE_TIME, PARSE_TIMESTAMP functions, > as specified by BigQuery. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5611) Show SQL query for failed tests for SqlOperatorTest
[
https://issues.apache.org/jira/browse/CALCITE-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5611:
Labels: pull-request-available (was: )
> Show SQL query for failed tests for SqlOperatorTest
> ---
>
> Key: CALCITE-5611
> URL: https://issues.apache.org/jira/browse/CALCITE-5611
> Project: Calcite
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.34.0
>Reporter: Sergey Nuyanzin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The issue is that there are lots of cases under each test in
> {{SqlOperatorTest}} and it is not clear which of them is failing.
> The idea is to print sql query from the test if it's failed besides
> type/result comparison
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5610) Implement COTH, CSCH, SECH Functions
[
https://issues.apache.org/jira/browse/CALCITE-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5610:
Labels: pull-request-available (was: )
> Implement COTH, CSCH, SECH Functions
>
>
> Key: CALCITE-5610
> URL: https://issues.apache.org/jira/browse/CALCITE-5610
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * {{COTH(X)}}: Computes the hyperbolic cotangent for the angle of {{X}},
> where {{X}} is specified in radians.
> [Docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#coth]
> * {{CSCH(X)}}: Computes the hyperbolic cosecant for the angle of {{X}}, where
> {{X}} is specified in radians.
> [Docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#csch]
> * {{SECH(X)}}: Computes the hyperbolic secant for the angle of {{X}}, where
> {{X}} is specified in radians.
> [Docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#sech]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5607) Serialize return type during RelJson.toJson(RexNode node) serialization
[
https://issues.apache.org/jira/browse/CALCITE-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5607:
Labels: pull-request-available (was: )
> Serialize return type during RelJson.toJson(RexNode node) serialization
>
>
> Key: CALCITE-5607
> URL: https://issues.apache.org/jira/browse/CALCITE-5607
> Project: Calcite
> Issue Type: Improvement
>Reporter: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We found a bug in {{RelJson#toRex}} for the {{TIMESTAMP_DIFF}} call for Big
> Query dialect.
> {{TIMESTAMP_DIFF}} is translated to the {{MINUS_DATE}}
> [operator|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L2113-L2116]
> with a return type explicitly declared as the interval.
> {{MINUS_DATE}} uses an
> {{[ARG2_NULLABLE|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L241]}}
> return type inference which requires 3 operands. This is fine in most cases
> where the RexCall is then used to generate SQL or for native implementations.
> However, in {{{}RelJson#toRex{}}}, when it tries to reconstruct the entire
> call to a RexNode, it attempts to derive the return type of the
> {{MINUS_DATE}} operator using the {{ARG2_NULLABLE}} inference. This throws an
> error as there are only 2 operands given to the {{MINUS_DATE}} operator.
> We'd like to now add in the "type" when serializing the JSON so that
> {{[jsonType|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L712]}}
> will be defined in {{{}toRex{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5606) Add SqlLibrary.ALL and change the library of TANH, COSH, SINH to it
[ https://issues.apache.org/jira/browse/CALCITE-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5606: Labels: pull-request-available (was: ) > Add SqlLibrary.ALL and change the library of TANH, COSH, SINH to it > --- > > Key: CALCITE-5606 > URL: https://issues.apache.org/jira/browse/CALCITE-5606 > Project: Calcite > Issue Type: Sub-task >Reporter: Dan Zou >Assignee: Dan Zou >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Add a new SqlLibrary named 'ALL' with abbreviation '*', if an operator is > marked with this SqlLibrary, it means it's a common one and should belong to > all the library. TANH, COSH, SINH are three of these operators. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5605) Add BigQuery as supported library for CHR
[
https://issues.apache.org/jira/browse/CALCITE-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5605:
Labels: pull-request-available (was: )
> Add BigQuery as supported library for CHR
> -
>
> Key: CALCITE-5605
> URL: https://issues.apache.org/jira/browse/CALCITE-5605
> Project: Calcite
> Issue Type: Task
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Calcite already supports the {{CHR}} function for Oracle and PostgreSQL.
> BigQuery supports it as well
> ([link|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#chr])
> so I would just like to enable it and add a couple more tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5581) Implement Basic client side load balancing in Avatica Driver
[
https://issues.apache.org/jira/browse/CALCITE-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5581:
Labels: pull-request-available (was: )
> Implement Basic client side load balancing in Avatica Driver
>
>
> Key: CALCITE-5581
> URL: https://issues.apache.org/jira/browse/CALCITE-5581
> Project: Calcite
> Issue Type: New Feature
> Components: avatica
>Affects Versions: 1.33.0
>Reporter: Vaibhav Joshi
>Assignee: Vaibhav Joshi
>Priority: Major
> Labels: pull-request-available
> Attachments: Avatica Basic client side load balancing.docx
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement mechanism to support Client side load balancing by configuring
> connection properties for load balancing
> {code:java}
> jdbc:phoenix:thin:
> url=https://:;
> serialization=PROTOBUF;
> authentication=BASIC;
> avatica_user=;
> avatica_password=
> useClientSideLB: [true/false]
> lbStrategy: [RandomDistribution/Sequential/RoundRobin]
> lbURLs: {code}
> Client should connect to any of the URLs specified in lbURLs ( depending on
> LB strategy selected). Please refer to [^Avatica Basic client side load
> balancing.docx]for more details
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5449) Allow EXTRACT() to accept time frames
[
https://issues.apache.org/jira/browse/CALCITE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5449:
Labels: pull-request-available (was: )
> Allow EXTRACT() to accept time frames
> -
>
> Key: CALCITE-5449
> URL: https://issues.apache.org/jira/browse/CALCITE-5449
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement BigQuery {{EXTRACT()}} Function. {{EXTRACT(part FROM
> date_expression)}} returns the value from the date_expression corresponding
> to the specified part. Calcite currently supports PostgreSQL' {{DATE_PART}}
> which has similar behavior.
> Example: {{SELECT EXTRACT(DAY FROM DATE '2013-12-25')}} would return 25.
> [BigQuery
> Docs|https://g3doc.corp.google.com/company/teams/googlesql/reference/date_functions.md#extract
> ]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5549) Appropriately set `DATA_TYPE` and `IS_GENERATEDCOLUMN` metadata values for `MEASURE` types
[
https://issues.apache.org/jira/browse/CALCITE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5549:
Labels: pull-request-available (was: )
> Appropriately set `DATA_TYPE` and `IS_GENERATEDCOLUMN` metadata values for
> `MEASURE` types
> --
>
> Key: CALCITE-5549
> URL: https://issues.apache.org/jira/browse/CALCITE-5549
> Project: Calcite
> Issue Type: Improvement
> Components: avatica, core
>Reporter: TJ Banghart
>Assignee: TJ Banghart
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{MEASURE}} types (introduced in
> [CALCITE-5105|https://issues.apache.org/jira/browse/CALCITE-5105]) currently
> present themselves as {{java.sql.Types#OTHER}}
> ({{}})([ref|https://docs.oracle.com/javase/8/docs/api/java/sql/Types.html#OTHER])
> It would be advantageous to surface the underlying data type of the
> {{MEASURE}} rather than catch all {{OTHER}} since the underlying data type is
> returned in result sets.
> For example a {{MEASURE}} (a measure of type integer) would appear
> as {{java.sql.Types#INTEGER}} ({{4}}).
> We should also set the {{IS_GENERATEDCOLUMN}} metadata value with this
> change. All {{MEASURE}} types would populate the column with {{"YES"}}
> otherwise {{"NO"}}.
> [Here's|https://github.com/apache/calcite/blob/2dba40e7a0a5651eac5a30d9e0a72f178bd9bff2/core/src/main/java/org/apache/calcite/jdbc/CalciteMetaImpl.java#L466]
> where the JDBC type gets set in {{CalciteMetaImpl}}.
> For {{IS_GENERATEDCOLUMN}} we will need a change to the {{MetaColumn}}
> [constructor in
> Avatica|https://github.com/apache/calcite-avatica/blob/b57eb7cd31a90d3f46b65c13832b398be5b0dad9/core/src/main/java/org/apache/calcite/avatica/MetaImpl.java#L359-L386]
> that will allow us to set this value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5596) Gradle test executor failed on Apple Silicon
[
https://issues.apache.org/jira/browse/CALCITE-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5596:
Labels: pull-request-available (was: )
> Gradle test executor failed on Apple Silicon
>
>
> Key: CALCITE-5596
> URL: https://issues.apache.org/jira/browse/CALCITE-5596
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.34.0
>Reporter: Lei Zhang
>Assignee: Lei Zhang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ./gradlew build
>
> {code:java}
> > Task :elasticsearch:testGradle Test Executor 8 STANDARD_OUT
> 2023-03-20 09:12:32,480 [ForkJoinPool-1-worker-3] WARN - unable to load
> JNA native support library, native methods will be disabled.
> java.lang.UnsatisfiedLinkError:
> /Users/zhanglei/Library/Caches/JNA/temp/jna186090715106003967.tmp:
> dlopen(/Users/zhanglei/Library/Caches/JNA/temp/jna186090715106003967.tmp,
> 0x0001): tried:
> '/Users/zhanglei/Library/Caches/JNA/temp/jna186090715106003967.tmp' (fat
> file, but missing compatible architecture (have (i386,x86_64), need (arm64e)))
> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> ~[?:1.8.0_332]
> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1950)
> ~[?:1.8.0_332]
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1832)
> ~[?:1.8.0_332]
> at java.lang.Runtime.load0(Runtime.java:811) ~[?:1.8.0_332]
> at java.lang.System.load(System.java:1088) ~[?:1.8.0_332]
> at
> com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
> ~[jna-5.5.0.jar:5.5.0 (b0)]
> at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
> ~[jna-5.5.0.jar:5.5.0 (b0)]
> at com.sun.jna.Native.(Native.java:195) ~[jna-5.5.0.jar:5.5.0
> (b0)]
> at java.lang.Class.forName0(Native Method) ~[?:1.8.0_332]
> at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_332]
> at org.elasticsearch.bootstrap.Natives.(Natives.java:45)
> ~[elasticsearch-7.10.2.jar:7.10.2]
> at
> org.elasticsearch.bootstrap.BootstrapInfo.isMemoryLocked(BootstrapInfo.java:50)
> ~[elasticsearch-7.10.2.jar:7.10.2]
> at
> org.elasticsearch.monitor.process.ProcessProbe.processInfo(ProcessProbe.java:130)
> ~[elasticsearch-7.10.2.jar:7.10.2]
> at
> org.elasticsearch.monitor.process.ProcessService.(ProcessService.java:47)
> ~[elasticsearch-7.10.2.jar:7.10.2]
> at
> org.elasticsearch.monitor.MonitorService.(MonitorService.java:45)
> ~[elasticsearch-7.10.2.jar:7.10.2]
> at org.elasticsearch.node.Node.(Node.java:433)
> ~[elasticsearch-7.10.2.jar:7.10.2]
> at
> org.apache.calcite.adapter.elasticsearch.EmbeddedElasticsearchNode$LocalNode.(EmbeddedElasticsearchNode.java:169)
> ~[test/:?]
> at
> org.apache.calcite.adapter.elasticsearch.EmbeddedElasticsearchNode$LocalNode.(EmbeddedElasticsearchNode.java:166)
> ~[test/:?]
> at
> org.apache.calcite.adapter.elasticsearch.EmbeddedElasticsearchNode.create(EmbeddedElasticsearchNode.java:69)
> ~[test/:?]
> at
> org.apache.calcite.adapter.elasticsearch.EmbeddedElasticsearchNode.create(EmbeddedElasticsearchNode.java:102)
> ~[test/:?]
> at
> org.apache.calcite.adapter.elasticsearch.EmbeddedElasticsearchPolicy$Singleton.(EmbeddedElasticsearchPolicy.java:74)
> ~[test/:?]
> at
> org.apache.calcite.adapter.elasticsearch.EmbeddedElasticsearchPolicy.create(EmbeddedElasticsearchPolicy.java:92)
> ~[test/:?]
> at
> org.apache.calcite.adapter.elasticsearch.BooleanLogicTest.(BooleanLogicTest.java:46)
> ~[test/:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.8.0_332]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:1.8.0_332]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_332]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_332]
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> ~[junit-platform-commons-1.9.1.jar:1.9.1]
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> ~[junit-jupiter-engine-5.9.1.jar:5.9.1]
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> ~[junit-jupiter-engine-5.9.1.jar:5.9.1]
> at
> org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> ~[junit-jupiter-engine-5.9.1.jar:5.9.1]
> at
>
[jira] [Updated] (CALCITE-5593) Elasticsearch Aliases query is not supported
[
https://issues.apache.org/jira/browse/CALCITE-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5593:
Labels: pull-request-available (was: )
> Elasticsearch Aliases query is not supported
>
>
> Key: CALCITE-5593
> URL: https://issues.apache.org/jira/browse/CALCITE-5593
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Affects Versions: 1.34.0
>Reporter: Lei Zhang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have a index is 'ndcp_metrics_collector_status_202303' and the alias is
> 'ndcp_metrics_collector_status'
> {code:java}
> {
> "ndcp_metrics_collector_status_202303":
> {
> "aliases":
> {
> "ndcp_metrics_collector_status":
> {}
> },
> "mappings":
> { {code}
> Query using index name is successful, but query using alias name fails
> {code:java}
> Exception in thread "main" java.sql.SQLException: Error while executing SQL
> "SELECT * FROM es.ndcp_metrics_collector_status WHERE _MAP['header.type'] =
> 'HEARTBEAT' offset 0 fetch next 3 rows only": From line 1, column 15 to line
> 1, column 46: Object 'NDCP_METRICS_COLLECTOR_STATUS' not found within 'es'
> 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 com.coolbeevip.calcite.elasticsearch.Main.main(Main.java:48)
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 15 to line 1, column 46: Object 'NDCP_METRICS_COLLECTOR_STATUS' not
> found within 'es'
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:945)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:930)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5464)
> at
> org.apache.calcite.sql.validate.IdentifierNamespace.resolveImpl(IdentifierNamespace.java:138)
> at
> org.apache.calcite.sql.validate.IdentifierNamespace.validateImpl(IdentifierNamespace.java:188)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1135)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1106)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3429)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3408)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3766)
> 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:1135)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1106)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:282)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1081)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:787)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:597)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:257)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:665)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:519)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:487)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:236)
> at
>
[jira] [Updated] (CALCITE-5361) Upgrade janino version to 3.1.9
[ https://issues.apache.org/jira/browse/CALCITE-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5361: Labels: pull-request-available (was: ) > Upgrade janino version to 3.1.9 > --- > > Key: CALCITE-5361 > URL: https://issues.apache.org/jira/browse/CALCITE-5361 > Project: Calcite > Issue Type: Improvement >Affects Versions: 1.32.0 >Reporter: Sergey Nuyanzin >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > This is a follow up task to update janino > it is not released yet. > while upgrade of Calcite to 1.28 for Flink > (https://issues.apache.org/jira/browse/FLINK-21239) I faced a number of > issues in janino > https://github.com/janino-compiler/janino/issues/185 > https://github.com/janino-compiler/janino/issues/186 > https://github.com/janino-compiler/janino/issues/187 > https://github.com/janino-compiler/janino/issues/188 > would be great to update janino once the fix version will be released -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5587) Upgrade geode-core from 1.10.0 to 1.15.1
[ https://issues.apache.org/jira/browse/CALCITE-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5587: Labels: pull-request-available (was: ) > Upgrade geode-core from 1.10.0 to 1.15.1 > > > Key: CALCITE-5587 > URL: https://issues.apache.org/jira/browse/CALCITE-5587 > Project: Calcite > Issue Type: Task > Components: geode-adapter >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Minor > Labels: pull-request-available > Fix For: 1.35.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5583) Rel2Sql will get an error when select * and join is present
[
https://issues.apache.org/jira/browse/CALCITE-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5583:
Labels: pull-request-available (was: )
> Rel2Sql will get an error when select * and join is present
> ---
>
> Key: CALCITE-5583
> URL: https://issues.apache.org/jira/browse/CALCITE-5583
> Project: Calcite
> Issue Type: Bug
>Reporter: libopeng
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Rel2Sql will get an error when select * and join is present
> {code:java}
> LogicalProject(c0=[$0], c00=[$1])
> LogicalJoin(condition=[=($0, $1)], joinType=[inner])
> LogicalProject(c0=[$0])
> LogicalTableScan(table=[[scott, EMP]])
> LogicalProject(c0=[$0])
> LogicalTableScan(table=[[scott, EMP]]){code}
> to sql
> {code:java}
> SELECT *
> FROM (SELECT "EMPNO" AS "c0"
> FROM "scott"."EMP") AS "t"
> INNER JOIN (SELECT "EMPNO" AS "c0"
> FROM "scott"."EMP") AS "t0" ON "t"."c0" = "t0"."c0" {code}
> When this sql is a subquery, it can be wrong
> {code:java}
> select *
> from "EMPNO" t1
> left join (
> SELECT * FROM (SELECT "EMPNO" AS "c0" FROM "scott"."EMP") AS "t" INNER JOIN
> (SELECT "EMPNO" AS "c0" FROM "scott"."EMP") AS "t0" ON "t"."c0" = "t0"."c0"
> ) t2
> on t1.EMPNO=t2."c0"{code}
> {color:#ff}fault: 'column reference "c0" is ambiguous' error when
> executing in postgresql{color}
> {color:#172b4d}[https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/rel/rel2sql/RelToSqlConverter.java#L451]{color}
> {color:#172b4d}Why add !isStar judgment here{color}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5574) Break MockCatalogReaderSimple#init into smaller methods
[
https://issues.apache.org/jira/browse/CALCITE-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5574:
Labels: pull-request-available (was: )
> Break MockCatalogReaderSimple#init into smaller methods
> ---
>
> Key: CALCITE-5574
> URL: https://issues.apache.org/jira/browse/CALCITE-5574
> Project: Calcite
> Issue Type: Improvement
> Components: tests
>Reporter: Benchao Li
>Assignee: Zou
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the
> [discussion|https://github.com/apache/calcite/pull/3092#discussion_r1131364712]
> of https://github.com/apache/calcite/pull/3092,
> {{MockCatalogReaderSimple#init}} is too long to add new code, we should break
> it into smaller ones. One possible way is to move each table registration to
> a separate one method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5585) Add STRPOS() Function (Enabled for BigQuery)
[
https://issues.apache.org/jira/browse/CALCITE-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5585:
Labels: pull-request-available (was: )
> Add STRPOS() Function (Enabled for BigQuery)
>
>
> Key: CALCITE-5585
> URL: https://issues.apache.org/jira/browse/CALCITE-5585
> Project: Calcite
> Issue Type: Improvement
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> BigQuery supports the {{STRPOS()}} function with accepts 2 {{STRINGS}} as
> arguments. The function returns the 1-based position of the first occurrence
> of the second string within the first (example below). If no occurrence is
> found, the function returns 0. The function also supports ByteStrings with
> the same behavior.
> EXAMPLE: {{STRPOS("abc", "bc")}} would return: {{2}}.
> EXAMPLE: {{STRPOS("abc", "d")}} would return: {{0}}.
> [BigQuery
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#strpos]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5567) Failed to apply plugin 'de.thetaphi.forbiddenapis' when running ./gradlew build w/ java19
[
https://issues.apache.org/jira/browse/CALCITE-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5567:
Labels: pull-request-available (was: )
> Failed to apply plugin 'de.thetaphi.forbiddenapis' when running ./gradlew
> build w/ java19
> -
>
> Key: CALCITE-5567
> URL: https://issues.apache.org/jira/browse/CALCITE-5567
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.33.0
> Environment: {{OS: arch linux}}
> {{JDK: java-19-openjdk}}
>Reporter: Matt P
>Priority: Major
> Labels: pull-request-available
> Attachments: build.gradle.kts, output.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Running {{./gradlew build}} on a fresh {{git clone}} fails with:
> {code:java}
> FAILURE: Build failed with an exception.
> * Where:
> Build file '/home/user/github/apache/calcite/build.gradle.kts' line: 513
> * What went wrong:
> Failed to apply plugin 'de.thetaphi.forbiddenapis'.
> > Could not create plugin of type 'ForbiddenApisPlugin'.
> > Could not initialize class
> de.thetaphi.forbiddenapis.gradle.ForbiddenApisPlugin
> {code}
> The full output (output.txt) and {{build.gradle.kts}} files are attached.
> This is similar to https://issues.apache.org/jira/browse/SOLR-14426 but
> running {{./gradlew clean}} results in the same error.
> I've tried this on version 1.33 plus several older releases with similar
> results.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5568) Decorrelate will fail. If the RelNode tree has LogicalValues
[
https://issues.apache.org/jira/browse/CALCITE-5568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5568:
Labels: pull-request-available (was: )
> Decorrelate will fail. If the RelNode tree has LogicalValues
>
>
> Key: CALCITE-5568
> URL: https://issues.apache.org/jira/browse/CALCITE-5568
> Project: Calcite
> Issue Type: Bug
>Reporter: libopeng
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Decorrelate will fail. If the RelNode tree has LogicalValues
> case:
> {code:java}
> SELECT
>(
>SELECT
> ( SUM ( "tbl2"."count" ) ) AS "SUM"
>FROM
> (
> SELECT
> (
> SELECT
> ( COUNT ( "tbl2"."id" ) ) AS "COUNT"
> FROM
> "trip_order" AS "tbl2"
> WHERE
> "tbl1"."province" = "tbl2"."province"
> ) AS "count",
> ( "tbl1"."province" ) AS "province"
> FROM
> "trip_order" AS "tbl1"
> ) AS "tbl2"
>) AS "sub_1"
> {code}
> after decorrelate
> (org.apache.calcite.sql2rel.RelDecorrelator#decorrelateQuery(org.apache.calcite.rel.RelNode,
> org.apache.calcite.tools.RelBuilder))
> {code:java}
> LogicalProject(sub_1=[$1])
> LogicalJoin(condition=[true], joinType=[left])
> LogicalValues(tuples=[[{ 0 }]])<
> LogicalAggregate(group=[{}], agg#0=[SINGLE_VALUE($0)])
> LogicalAggregate(group=[{}], SUM=[SUM($0)])
> LogicalProject(count=[$10])
> LogicalProject(id=[$0], gmt_create=[$1], service_begin=[$2],
> driver_id=[$3], passenger_id=[$4], province=[$5], city=[$6],
> service_minute=[$7], service_mileage=[$8], order_amount=[$9], $f0=[$10])
> LogicalProject(id=[$0], gmt_create=[$1], service_begin=[$2],
> driver_id=[$3], passenger_id=[$4], province=[$5], city=[$6],
> service_minute=[$7], service_mileage=[$8], order_amount=[$9], $f0=[$10])
> LogicalCorrelate(correlation=[$cor0], joinType=[left],
> requiredColumns=[{5}]) < See here, the decorrelate didn't work
> LogicalTableScan(table=[[trip_order]])
> LogicalAggregate(group=[{}], agg#0=[SINGLE_VALUE($0)])
> LogicalAggregate(group=[{}], COUNT=[COUNT()])
> LogicalFilter(condition=[=($cor0.province, $5)])
> LogicalTableScan(table=[[trip_order]]){code}
> LogicalCorrelate will not be processed when the RelNode tree has
> LogicalValues
> [https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L491]
>
> Is this as expected？
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5580) Add SPLIT() Function (Enabled for BigQuery)
[
https://issues.apache.org/jira/browse/CALCITE-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5580:
Labels: pull-request-available (was: )
> Add SPLIT() Function (Enabled for BigQuery)
> ---
>
> Key: CALCITE-5580
> URL: https://issues.apache.org/jira/browse/CALCITE-5580
> Project: Calcite
> Issue Type: Improvement
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> BigQuery offers the {{SPLIT()}} function which splits a string at an
> optionally-specified delimiter into a string array. If no delimiter is
> specified, it is default to a comma. If the string is empty, an array of a
> single empty string is returned. If the delimiter is not found in the string,
> an array with a single element (the string) is returned.
> In BigQuery, the function can also accept bytes. In order to implement this,
> I think some modifications to ByteString.java may be required. I will
> probably not do this at least for my initial draft. If anyone has any
> suggestions or guidance on whether or not it should be supported, I would
> appreciate it.
> Documentation and example cases may be found below.
> EXAMPLE: {{SPLIT('h,e,l,l,o')}} would return: {{[h, e, l, l, o]}}.
> EXAMPLE: {{SPLIT('h-e-l-l-o')}} would return: {{[h, e, l, l, o]}}.
> [BigQuery
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#split]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5577) Map value constructor is unparsed incorrectly for SparkSqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5577:
Labels: pull-request-available (was: )
> Map value constructor is unparsed incorrectly for SparkSqlDialect
> -
>
> Key: CALCITE-5577
> URL: https://issues.apache.org/jira/browse/CALCITE-5577
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.33.0
>Reporter: Guillaume Massé
>Assignee: Guillaume Massé
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> They should be in the form: map('k1', 'v1', 'k2', 'v2')
> However, they are unparsed as MAP['k1', 'v1', 'k2', 'v2']
> [https://spark.apache.org/docs/latest/api/sql/#map|https://spark.apache.org/docs/latest/api/sql/#array]
>
> I would be happy to submit a fix,
> Guillaume
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5576) Upgrade kotlin from 1.5.31 to 1.8.10
[ https://issues.apache.org/jira/browse/CALCITE-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5576: Labels: pull-request-available (was: ) > Upgrade kotlin from 1.5.31 to 1.8.10 > > > Key: CALCITE-5576 > URL: https://issues.apache.org/jira/browse/CALCITE-5576 > Project: Calcite > Issue Type: Task >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Trivial > Labels: pull-request-available > Fix For: 1.35.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-4554) TIMESTAMP WITH LOCAL TIME ZONE type is not supported in Snapshot and MatchRecognize validation
[ https://issues.apache.org/jira/browse/CALCITE-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-4554: Labels: pull-request-available (was: ) > TIMESTAMP WITH LOCAL TIME ZONE type is not supported in Snapshot and > MatchRecognize validation > --- > > Key: CALCITE-4554 > URL: https://issues.apache.org/jira/browse/CALCITE-4554 > Project: Calcite > Issue Type: Improvement >Reporter: Leonard Xu >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > When I plan to support *TIMESTAMP WITH LOCAL TIME ZONE* type in Flink > project , I found only *TIMESTAMP* is supported in system period type of > *Snapshot* node and first orderBy column type of *MatchRecognize* node in > Calcite. So I have to override the class > _org.apache.calcite.sql.validate.SqlValidatorImpl_ to skip the validate > logic. > Both *TIMESTAMP* and *TIMESTAMP WITH LOCAL TIME ZONE* belong to > *SqlTypeFamily.TIMESTAMP*, Could we also support *TIMESTAMP WITH LOCAL TIME > ZONE* in these situations? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5570) Support nested map type for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5570:
Labels: pull-request-available (was: )
> Support nested map type for SqlDataTypeSpec
> ---
>
> Key: CALCITE-5570
> URL: https://issues.apache.org/jira/browse/CALCITE-5570
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There was added a similar support for arrays/multisets at
> https://issues.apache.org/jira/browse/CALCITE-3250
> however there is no support for maps so far.
> The issue is to add such support.
>
> I think I'd like to clarify is syntax for maps since it has 2 internal
> subtypes for keys and values may be something similar to ROW with delimiter
> like
> {code:sql}
> SELECT CAST(NULL AS MAP(INT, INT));
> -- or with square brackets similar to map constructor
> SELECT CAST(NULL AS MAP[INT, INT]);
> -- or with angle (Flink syntax)
> SELECT CAST(NULL AS MAP);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-4698) Return type of timestampadd(..., ..., timestamp_ltz) should be timestamp_ltz instead of timestamp
[
https://issues.apache.org/jira/browse/CALCITE-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4698:
Labels: pull-request-available (was: )
> Return type of timestampadd(..., ..., timestamp_ltz) should be timestamp_ltz
> instead of timestamp
> -
>
> Key: CALCITE-4698
> URL: https://issues.apache.org/jira/browse/CALCITE-4698
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Caizhi Weng
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently {{SqlTimestampAddFunction#deduceType}} does not deal with
> timestamp_ltz type correctly. Return type of {{timestampadd(..., ...,
> timestamp_ltz)}} will be timestamp but it should be timestamp_ltz.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5572) Release Calcite 1.34.0
[ https://issues.apache.org/jira/browse/CALCITE-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5572: Labels: pull-request-available (was: ) > Release Calcite 1.34.0 > -- > > Key: CALCITE-5572 > URL: https://issues.apache.org/jira/browse/CALCITE-5572 > Project: Calcite > Issue Type: Task >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5571) Remove org.jetbrains.annotations from java source code
[
https://issues.apache.org/jira/browse/CALCITE-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5571:
Labels: pull-request-available (was: )
> Remove org.jetbrains.annotations from java source code
> --
>
> Key: CALCITE-5571
> URL: https://issues.apache.org/jira/browse/CALCITE-5571
> Project: Calcite
> Issue Type: Task
>Affects Versions: 1.33.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the most part we are using checkerframework annotations
> (org.checkerframework.checker.nullness.qual) for specifying nullability.
> There are 2 places, namely {{ScannableTableTest}} and {{UtilTest}} where we
> have nullability annotations from org.jetbrains.annotations package.
> To keep things consistent and also avoid mixing up annotations from different
> providers in the future, I propose to remove the last references to
> org.jetbrains.annotations and exclude the org.jetbrains:annotations
> dependency from the build to avoid accidentally using such annotations in the
> future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5559) Improve RepeatUnion by discarding duplicates at TableSpool level
[ https://issues.apache.org/jira/browse/CALCITE-5559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5559: Labels: pull-request-available (was: ) > Improve RepeatUnion by discarding duplicates at TableSpool level > > > Key: CALCITE-5559 > URL: https://issues.apache.org/jira/browse/CALCITE-5559 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Ruben Q L >Assignee: Ruben Q L >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Currently, RepeatUnion operator with all=false keeps track of the elements > that it has returned in order to discard duplicates. However, the TableSpool > operators that are right below it do not have such control. In certain > scenarios, duplicates are returned by the TableSpool current iteration, > discarded by the RepeatUnion, but have been already "fed back" by the > TableSpool into the next iteration, causing unnecessary processing. > We can optimize this scenario by keeping track of the duplicates > inside/before the TableSpool too (note: we still need to keep track of > duplicates at RepeatUnion level, because that is the only place where we can > detect a potential "global duplicate" of an element: returned by the LHS and > then also by the RHS, or by two different iterations of the RHS). > A PoC testing this improvement on a downstream project showed that certain > queries can go from ~40s down to ~1s. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5548) Add support for MSSQL CONVERT function
[
https://issues.apache.org/jira/browse/CALCITE-5548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5548:
Labels: pull-request-available (was: )
> Add support for MSSQL CONVERT function
> --
>
> Key: CALCITE-5548
> URL: https://issues.apache.org/jira/browse/CALCITE-5548
> Project: Calcite
> Issue Type: Improvement
>Reporter: Askar Bozcan
>Assignee: Askar Bozcan
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add support for MSSQL CONVERT function (which is the same as CAST, with
> optional formatting)
> More info:
> [https://learn.microsoft.com/en-us/sql/t-sql/functions/cast-and-convert-transact-sql?view=sql-server-ver16]
> Example usage:
> {{SELECT CONVERT(DATETIME, '2017-08-25', 101)}}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5565) Implement BigQuery LOG function
[
https://issues.apache.org/jira/browse/CALCITE-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5565:
Labels: pull-request-available (was: )
> Implement BigQuery LOG function
> ---
>
> Key: CALCITE-5565
> URL: https://issues.apache.org/jira/browse/CALCITE-5565
> Project: Calcite
> Issue Type: Task
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Calcite currently supports the {{LN}} and {{LOG10}} function. BigQuery offers
> the {{LOG}} function which allows for the base of the logarithm to be
> specified as a second argument. If the second argument is not provided, the
> base is defaulted to e (making it identical to the {{LN}} function.
> Example: {{LOG(64, 10)}} would return {{2}}.
> Example 2: {{LOG(10)}} would return the same as {{LN(10)}}.
> [BigQuery
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#log]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5563) Add a break to the inner loop of RelSubset#getParents and RelSubset#getParentSubsets after we find a matching Relsubset from its parent input
[
https://issues.apache.org/jira/browse/CALCITE-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5563:
Labels: pull-request-available (was: )
> Add a break to the inner loop of RelSubset#getParents and
> RelSubset#getParentSubsets after we find a matching Relsubset from its parent
> input
> -
>
> Key: CALCITE-5563
> URL: https://issues.apache.org/jira/browse/CALCITE-5563
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: asdfgh19
>Assignee: asdfgh19
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.34.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> {code:java}
> /**
> * Returns the collection of RelNodes one of whose inputs is in this
> * subset.
> */
> Set getParents() {
> final Set list = new LinkedHashSet<>();
> for (RelNode parent : set.getParentRels()) {
> for (RelSubset rel : inputSubsets(parent)) {
> // see usage of this method in propagateCostImprovements0()
> if (rel == this) {
> list.add(parent);
> break;
> }
> }
> }
> return list;
> }
> /**
> * Returns the collection of distinct subsets that contain a RelNode one
> * of whose inputs is in this subset.
> */
> Set getParentSubsets(VolcanoPlanner planner) {
> final Set list = new LinkedHashSet<>();
> for (RelNode parent : set.getParentRels()) {
> for (RelSubset rel : inputSubsets(parent)) {
> if (rel.set == set && rel.getTraitSet().equals(traitSet)) {
> list.add(planner.getSubsetNonNull(parent));
> break;
> }
> }
> }
> return list;
> }{code}
>
> Once we have found a matching Relsubset from its parent input, we can
> immediately end the inner loop.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5553) Calcite RelStructuredTypeFlattener produces bad plan for single field structs
[
https://issues.apache.org/jira/browse/CALCITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5553:
Labels: pull-request-available (was: )
> Calcite RelStructuredTypeFlattener produces bad plan for single field structs
> -
>
> Key: CALCITE-5553
> URL: https://issues.apache.org/jira/browse/CALCITE-5553
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0, 1.28.0, 1.33.0
>Reporter: Andrew Pilloud
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A Beam user brought us a query that produces an invalid plan after
> upgrading to a newer version of Beam (moving them from Calcite 1.20 to
> 1.28). I was able to write a test case which demonstrates this issue
> with a trivial filter on a table containing a nested struct with a
> single field. The issue appears to be coming out of
> RelStructuredTypeFlattener.rewrite and I bisected it to a single
> commit,
> [e44beba28|https://github.com/apache/calcite/commit/e44beba286ea9049c5fd00c3a3b0e4a4f1c03356].
> Removing the noFlatteningForInput function added in this commit fixes
> the issue. That method doesn't appear to be looking at types at all,
> only mismatches in field count, I expect so any single field struct
> would hit this. Any suggestions on how we can work around this in
> Beam?
> The test query and plans are as follows, the test case is in [PR
> 3092|https://github.com/apache/calcite/pull/3092].
> {code}
> select dn.skill from sales.dept_single dn WHERE dn.skill.type = ''
> {code}
> Expected plan:
> {noformat}
> LogicalProject(SKILL=[ROW($0)])
> LogicalFilter(condition=[=($0, '')])
> LogicalProject(TYPE=[$0.TYPE])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
> {noformat}
> Actual Plan:
> {noformat}
> LogicalProject(SKILL=[ROW($0)])
> LogicalFilter(condition=[=($0.TYPE, '')])
> LogicalProject(TYPE=[$0.TYPE])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
> {noformat}
> Plan before flatten:
> {noformat}
> LogicalProject(SKILL=[$0])
> LogicalFilter(condition=[=($0.TYPE, '')])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5554) Add DAYOFWEEK and DAYOFYEAR as valid synonyms of DOW, DOY
[
https://issues.apache.org/jira/browse/CALCITE-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5554:
Labels: pull-request-available (was: )
> Add DAYOFWEEK and DAYOFYEAR as valid synonyms of DOW, DOY
> -
>
> Key: CALCITE-5554
> URL: https://issues.apache.org/jira/browse/CALCITE-5554
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, a query such as: {{EXTRACT(DAYOFWEEK FROM DATE '2008-12-25');}} is
> invalid while {{EXTRACT(DOW FROM DATE '2008-12-25')}} is acceptable. BigQuery
> (and perhaps other dialects) accept the non-abbreviated version as a valid
> time unit. After this change, DAYOFWEEK and DAYOFYEAR would both be synonyms
> of DOW and DOY, respectively.
> [Relevant BigQuery
> Docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/date_functions#extract]
> Any comments, questions, or suggestions for the linked PR are highly
> appreciated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5551) Implement SELECT * EXCEPT field
[ https://issues.apache.org/jira/browse/CALCITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5551: Labels: pull-request-available (was: ) > Implement SELECT * EXCEPT field > --- > > Key: CALCITE-5551 > URL: https://issues.apache.org/jira/browse/CALCITE-5551 > Project: Calcite > Issue Type: Improvement >Reporter: Erlend Hamnaberg >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Some databases like bigquery support SELECT * Except (field1, field2) > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5550) Update instructions for requesting Jira account to use self-serve facility
[ https://issues.apache.org/jira/browse/CALCITE-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5550: Labels: pull-request-available (was: ) > Update instructions for requesting Jira account to use self-serve facility > -- > > Key: CALCITE-5550 > URL: https://issues.apache.org/jira/browse/CALCITE-5550 > Project: Calcite > Issue Type: Task > Components: site >Reporter: Francis Chuang >Assignee: Francis Chuang >Priority: Trivial > Labels: pull-request-available > Fix For: 1.34.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Annoucement: https://lists.apache.org/thread/k2p68qhd4whopjbhvj62xtbh55qg2blm -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5476) Add DATETIME_TRUNC for BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5476:
Labels: pull-request-available (was: )
> Add DATETIME_TRUNC for BigQuery
> ---
>
> Key: CALCITE-5476
> URL: https://issues.apache.org/jira/browse/CALCITE-5476
> Project: Calcite
> Issue Type: Improvement
>Reporter: Oliver Lee
>Assignee: Oliver Lee
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Adding in DATETIME_TRUNC() to the BigQuery library as described here:
> [https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#datetime_trunc]
> Truncates a {{DATETIME}} value to the granularity of {{{}date_time_part{}}}.
> The {{DATETIME}} value is always rounded to the beginning of
> {{{}date_time_part{}}}, which can be one of the following:
> * {{{}MICROSECOND{}}}: If used, nothing is truncated from the value.
> * {{{}MILLISECOND{}}}: The nearest lessor or equal millisecond.
> * {{{}SECOND{}}}: The nearest lessor or equal second.
> * {{{}MINUTE{}}}: The nearest lessor or equal minute.
> * {{{}HOUR{}}}: The nearest lessor or equal hour.
> * {{{}DAY{}}}: The day in the Gregorian calendar year that contains the
> {{DATETIME}} value.
> * {{{}WEEK{}}}: The first day of the week in the week that contains the
> {{DATETIME}} value. Weeks begin on Sundays. {{WEEK}} is equivalent to
> {{{}WEEK(SUNDAY){}}}.
> * {{{}WEEK(WEEKDAY){}}}: The first day of the week in the week that contains
> the {{DATETIME}} value. Weeks begin on {{{}WEEKDAY{}}}. {{WEEKDAY}} must be
> one of the following: {{{}SUNDAY{}}}, {{{}MONDAY{}}}, {{{}TUESDAY{}}},
> {{{}WEDNESDAY{}}}, {{{}THURSDAY{}}}, {{{}FRIDAY{}}}, or {{{}SATURDAY{}}}.
> * {{{}ISOWEEK{}}}: The first day of the [ISO 8601
> week|https://en.wikipedia.org/wiki/ISO_week_date] in the ISO week that
> contains the {{DATETIME}} value. The ISO week begins on Monday. The first ISO
> week of each ISO year contains the first Thursday of the corresponding
> Gregorian calendar year.
> * {{{}MONTH{}}}: The first day of the month in the month that contains the
> {{DATETIME}} value.
> * {{{}QUARTER{}}}: The first day of the quarter in the quarter that contains
> the {{DATETIME}} value.
> * {{{}YEAR{}}}: The first day of the year in the year that contains the
> {{DATETIME}} value.
> * {{{}ISOYEAR{}}}: The first day of the [ISO
> 8601|https://en.wikipedia.org/wiki/ISO_8601] week-numbering year in the ISO
> year that contains the {{DATETIME}} value. The ISO year is the Monday of the
> first week whose Thursday belongs to the corresponding Gregorian calendar
> year.
>
>
> {{SELECT DATETIME_TRUNC(DATETIME "2008-12-25 15:30:00", DAY) ->
> 2008-12-25T00:00:00}}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5367) Implement missing spatial type functions
[ https://issues.apache.org/jira/browse/CALCITE-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5367: Labels: pull-request-available (was: ) > Implement missing spatial type functions > > > Key: CALCITE-5367 > URL: https://issues.apache.org/jira/browse/CALCITE-5367 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Bertil Chapuis >Assignee: Bertil Chapuis >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The following spatial measurement functions are yet to be implemented: > * ST_AddPoint > * ST_CollectionExtract > * ST_Densify > * ST_FlipCoordinates > * ST_Holes > * ST_Normalize > * ST_RemoveDuplicatedCoordinates > * ST_RemoveHoles > * ST_RemovePoints > * ST_RemoveRepeatedPoints > * ST_Reverse -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5435) Insert for multi row VALUES failed when column has values of different types
[
https://issues.apache.org/jira/browse/CALCITE-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5435:
Labels: pull-request-available (was: )
> Insert for multi row VALUES failed when column has values of different types
>
>
> Key: CALCITE-5435
> URL: https://issues.apache.org/jira/browse/CALCITE-5435
> Project: Calcite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Queries like:
> {noformat}
> insert into empnullables (empno) values (10), ('20'){noformat}
> Or:
> {noformat}
> insert into empnullables (empno, deptno) values (10, '300'), (20,
> null){noformat}
> Fail with an exception:
> {noformat}
> From line 2, column 1 to line 2, column 32: Values passed to VALUES operator
> must have compatible types
> org.apache.calcite.runtime.CalciteContextException: From line 2, column 1 to
> line 2, column 32: Values passed to VALUES operator must have compatible types
> ...
> at
> app//org.apache.calcite.sql.validate.SqlValidatorImpl.validateValues(SqlValidatorImpl.java:5370){noformat}
> In the first query, first row has column type INTEGER and second row has
> column type CHAR(2).
> In the second query data type of {{null}} is infered from target data type
> (INTEGER).
> However types of values can be coerced.
> In case of one-by-one inserts statements work as expected. For one-row
> inserts this check is skipped and types are coerced later in
> {{SqlValidatorImpl#validateInsert}} -> {{{}checkTypeAssignment{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5530) RelToSqlConverter[ORDER BY] generates an incorrect field alias when 2 projection fields have the same name
[
https://issues.apache.org/jira/browse/CALCITE-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5530:
Labels: pull-request-available (was: )
> RelToSqlConverter[ORDER BY] generates an incorrect field alias when 2
> projection fields have the same name
> --
>
> Key: CALCITE-5530
> URL: https://issues.apache.org/jira/browse/CALCITE-5530
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.33.0
>Reporter: Abbas Gadhia
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In queries typical of Teradata,
> if there exists an expression alias that is also a field in the underlying
> table, any references to that field in the ORDER BY, refer to the underlying
> physical column rather than the expression alias.
> For ex. in the following query and Rel
>
> {code:java}
> SELECT UPPER(ENAME) AS EMPNO FROM scott.EMP order by EMPNO;{code}
> {noformat}
> LogicalProject(EMPNO=[$0])
> LogicalSort(sort0=[$1], dir0=[ASC])
> LogicalProject(EMPNO=[UPPER($1)], EMPNO0=[$0])
> LogicalTableScan(table=[[scott, EMP]]){noformat}
> EMPNO actually refers to the underlying physical column.
>
> The output of RelToSqlConverter is the following
> {code:java}
> SELECT UPPER(ENAME) AS EMPNO FROM scott.EMP order by EMPNO0;
> SELECT UPPER(ENAME) AS EMPNO FROM scott.EMP ORDER BY 2;{code}
> Here EMPNO0 or ordinal 2 does not exist and fails.
>
> This issue, i believe was introduced due to the changes done as part of
> https://issues.apache.org/jira/browse/CALCITE-4901
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5545) Allow for overriding SqlValidator to enable custom SqlNode validation
[
https://issues.apache.org/jira/browse/CALCITE-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5545:
Labels: pull-request-available (was: )
> Allow for overriding SqlValidator to enable custom SqlNode validation
> -
>
> Key: CALCITE-5545
> URL: https://issues.apache.org/jira/browse/CALCITE-5545
> Project: Calcite
> Issue Type: Bug
>Reporter: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Goal: Be able to enable custom SqlNode validation
> It will require overloading {{CalcitePrepareImpl}}, setting the
> {{prepareFactory}} in {{Driver.java}} to use the overloaded
> {{CalcitePrepareImpl}}, and then overloading {{createSqlValidator()}} and
> {{getSqlValidator()}} of {{CalcitePreparingStmt}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5537) Slow test case failures in LatticeSuggesterTest
[ https://issues.apache.org/jira/browse/CALCITE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5537: Labels: pull-request-available (was: ) > Slow test case failures in LatticeSuggesterTest > --- > > Key: CALCITE-5537 > URL: https://issues.apache.org/jira/browse/CALCITE-5537 > Project: Calcite > Issue Type: Test >Reporter: peng wang >Assignee: peng wang >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > LatticeSuggesterTest#testFoodMartAll > LatticeSuggesterTest#testFoodMartAllEvolve > may be failed in slow test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5536) Clean up some of the magic numbers in AvaticaResultSetConversionsTest
[ https://issues.apache.org/jira/browse/CALCITE-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5536: Labels: pull-request-available (was: ) > Clean up some of the magic numbers in AvaticaResultSetConversionsTest > - > > Key: CALCITE-5536 > URL: https://issues.apache.org/jira/browse/CALCITE-5536 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Will Noble >Priority: Trivial > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Retroactively filing this bug for some [cleanup I > did|https://github.com/apache/calcite-avatica/pull/208] in preparation for > the fix to CALCITE-5446. This cleanup makes the fix and accompanied test > adjustments easier to review. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5535) Time values are not properly truncated
[
https://issues.apache.org/jira/browse/CALCITE-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5535:
Labels: pull-request-available (was: )
> Time values are not properly truncated
> --
>
> Key: CALCITE-5535
> URL: https://issues.apache.org/jira/browse/CALCITE-5535
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Will Noble
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Avatica [uses the binary modulo
> operator|https://github.com/apache/calcite-avatica/blob/810acf80771310431d7ef576f3404299ebb8eaf2/core/src/main/java/org/apache/calcite/avatica/util/AbstractCursor.java#L1164]
> to truncate time values by the number of milliseconds in a day, but this
> operator can result in negative numbers. We should use {{Math.floorMod()}}
> instead. There are also places where numbers are not truncated at all, such
> as when [converting to
> string|https://github.com/apache/calcite-avatica/blob/810acf80771310431d7ef576f3404299ebb8eaf2/core/src/main/java/org/apache/calcite/avatica/util/AbstractCursor.java#L262].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5518) RelToSql converter generates invalid order of ROLLUP fields
[
https://issues.apache.org/jira/browse/CALCITE-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5518:
Labels: pull-request-available (was: )
> RelToSql converter generates invalid order of ROLLUP fields
> ---
>
> Key: CALCITE-5518
> URL: https://issues.apache.org/jira/browse/CALCITE-5518
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.32.0
>Reporter: Leonid Chistov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> RelToSqlConverter generates wrong code for Aggregate nodes with grouping sets
> classified as `ROLLUP` grouping but with order of rollup not matching order
> of grouping fields.
> This can be demonstrated by the following test, that would fail if added to
> RelToSqlConverterTest class:
> {code:java}
> @Test void testGroupingSetsRollupNonNaturalOrder() {
> final String query = "select \"product_class_id\", \"brand_name\"\n"
> + "from \"product\"\n"
> + "group by GROUPING SETS ((\"product_class_id\", \"brand_name\"),"
> + " (\"brand_name\"), ())\n";
> final String expected = "SELECT \"product_class_id\", \"brand_name\"\n"
> + "FROM \"foodmart\".\"product\"\n"
> + "GROUP BY ROLLUP (\"brand_name\", \"product_class_id\")";
> sql(query)
> .withPostgresql().ok(expected);
> }{code}
> As the result we get the following SQL code:
> {code:java}
> SELECT product_class_id, brand_name
> FROM foodmart.product
> GROUP BY ROLLUP(product_class_id, brand_name){code}
> While the correct code would be:
> {code:java}
> SELECT product_class_id, brand_name
> FROM foodmart.product
> GROUP BY ROLLUP(brand_name, product_class_id){code}
> Source of the bug is that we treat grouping sets \{0, 1}, \{1}, {} as rollup
> grouping, but right after that we generate SQL code as if grouping sets were
> \{0, 1}, \{0}, {}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5515) Keyspace in CQL sessions cannot be optional
[
https://issues.apache.org/jira/browse/CALCITE-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5515:
Labels: pull-request-available (was: )
> Keyspace in CQL sessions cannot be optional
> ---
>
> Key: CALCITE-5515
> URL: https://issues.apache.org/jira/browse/CALCITE-5515
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
>Reporter: Tim Nieradzik
>Assignee: Tim Nieradzik
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In our database solution, we {color:#00}construct `CassandraSchema`
> instances ourselves (bypassing `CassandraSchemaFactory`) as users may
> configure Cassandra datasources without specifying a default keyspace.{color}
> Currently, it is not possible to construct a `CassandraSchema` instance if
> the keyspace is not set in the CQL session.
> Furthermore, queries generated by `CassandraTable` do not include a keyspace
> and will fail if the CQL session does not have a keyspace set.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
