[jira] [Commented] (CALCITE-3986) Provide config option to omit assigning an alias that is identical to its identifier.
[ https://issues.apache.org/jira/browse/CALCITE-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147970#comment-17147970 ] Drew Schmitt commented on CALCITE-3986: --- Thanks [~julianhyde]. The test case testOmitRedundantAlias() looks good to me. > Provide config option to omit assigning an alias that is identical to its > identifier. > - > > Key: CALCITE-3986 > URL: https://issues.apache.org/jira/browse/CALCITE-3986 > Project: Calcite > Issue Type: Improvement >Reporter: Drew Schmitt >Assignee: Julian Hyde >Priority: Minor > > The current alias assignment logic with the SqlValidator config option > identifierExpansion() set to true will eagerly try to choose an alias, even > if the alias name ends up being the same as the identifier itself. For > example, it will assign the alias "foo" for the table "foo". > It's nice to have alias assignment, but making it identical to the identifier > doesn't always provide a whole lot of value and can make queries more verbose > than they need to be. > Suggest we add another SqlValidator config option (defaulted to the current > behavior) to allow a caller to disable alias assignment in the cases that it > would be identical to the identifier. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3946) Add parser support for MULTISET/SET and VOLATILE modifiers in CREATE TABLE statements
[
https://issues.apache.org/jira/browse/CALCITE-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119885#comment-17119885
]
Drew Schmitt commented on CALCITE-3946:
---
[~julianhyde], that sounds good to me - thanks!
> Add parser support for MULTISET/SET and VOLATILE modifiers in CREATE TABLE
> statements
> -
>
> Key: CALCITE-3946
> URL: https://issues.apache.org/jira/browse/CALCITE-3946
> Project: Calcite
> Issue Type: Improvement
> Components: babel
>Affects Versions: 1.22.0
>Reporter: Drew Schmitt
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.24.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Add support to Calcite's Babel parser for {{MULTISET}}/{{SET}} and
> {{VOLATILE}} modifiers in {{CREATE TABLE}} statements.
> The syntax for these statements is:
> {code:sql}
> CREATE TABLE [SET|MULTISET] [VOLATILE]
>[IF NOT EXISTS] ( , ...);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3986) Provide config option to omit assigning an alias that is identical to its identifier.
[ https://issues.apache.org/jira/browse/CALCITE-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111444#comment-17111444 ] Drew Schmitt commented on CALCITE-3986: --- I mean that it would be nice to be able to keep aliases if they're assigned by the user, but to avoid rendering them in the resulting SQL if they are auto-generated/redundant aliases. For example, for the following input query: select a from abc After parsing into an AST and unparsing to BigQuerySql results in the following query: SELECT a FROM abc AS abc While technically correct, having the extra "AS abc" alias seems like a redundant/more verbose form. > Provide config option to omit assigning an alias that is identical to its > identifier. > - > > Key: CALCITE-3986 > URL: https://issues.apache.org/jira/browse/CALCITE-3986 > Project: Calcite > Issue Type: Improvement >Reporter: Drew Schmitt >Priority: Minor > > The current alias assignment logic with the SqlValidator config option > identifierExpansion() set to true will eagerly try to choose an alias, even > if the alias name ends up being the same as the identifier itself. For > example, it will assign the alias "foo" for the table "foo". > It's nice to have alias assignment, but making it identical to the identifier > doesn't always provide a whole lot of value and can make queries more verbose > than they need to be. > Suggest we add another SqlValidator config option (defaulted to the current > behavior) to allow a caller to disable alias assignment in the cases that it > would be identical to the identifier. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3987) Allow addition and subtraction operations between DATE and NUMERIC types.
[ https://issues.apache.org/jira/browse/CALCITE-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110719#comment-17110719 ] Drew Schmitt commented on CALCITE-3987: --- Thanks for the recommendation, Danny! I decided to try out option #2. I was also able to hide this coercion behind a SqlConformanceEnum.BABEL check. > Allow addition and subtraction operations between DATE and NUMERIC types. > - > > Key: CALCITE-3987 > URL: https://issues.apache.org/jira/browse/CALCITE-3987 > Project: Calcite > Issue Type: Improvement >Reporter: Drew Schmitt >Priority: Minor > > We should allow addition (PLUS operator) and subtraction (MINUS operator) > between DATE and NUMERIC types to be valid during the validation phase. > Downstream, the result of the operation can be interpreted differently > depending on the dialect. For example, some dialects would interpret any > arithmetic with a DATE as implying adding/subtracting a number of days. > Example query: > CREATE TABLE foo (bar DATE); > SELECT bar - 1 FROM foo; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3987) Allow addition and subtraction operations between DATE and NUMERIC types.
[ https://issues.apache.org/jira/browse/CALCITE-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108777#comment-17108777 ] Drew Schmitt commented on CALCITE-3987: --- Thanks Julian. I like the idea of going with the conformance approach. However, I'm having difficulty figuring out how to make that work. It looks like the SqlStdOperatorTable.PLUS operator is being assigned during parsing here: https://github.com/apache/calcite/blob/master/core/src/main/codegen/templates/Parser.jj#L6652 which is using the OperandTypes.PLUS_OPERATOR operand type checker here: https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlStdOperatorTable.java#L542 So, my initial thought was to add something like DATE_NUMERIC and NUMERIC_DATE to the PLUS_OPERATOR here: https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/type/OperandTypes.java#L478 If we want to only enable this functionality for certain conformance values (e.g. SqlConformanceEnum.BABEL), is the recommended approach to edit Parser.jj to conditionally return a different operator at parsing time (instead of SqlStdOperatorTable.PLUS) which supports numeric and date operands? Or is there a way to replace/overload the PLUS operator with our own custom one that supports numeric and date operands during the validation stage? I came across OracleSqlOperatorTable, which looked like a promising model to follow for a new class which extends ReflectiveSqlOperatorTable to support our new PLUS operator. However, that appears to be deprecated. Any recommendations would be greatly appreciated! > Allow addition and subtraction operations between DATE and NUMERIC types. > - > > Key: CALCITE-3987 > URL: https://issues.apache.org/jira/browse/CALCITE-3987 > Project: Calcite > Issue Type: Improvement >Reporter: Drew Schmitt >Priority: Minor > > We should allow addition (PLUS operator) and subtraction (MINUS operator) > between DATE and NUMERIC types to be valid during the validation phase. > Downstream, the result of the operation can be interpreted differently > depending on the dialect. For example, some dialects would interpret any > arithmetic with a DATE as implying adding/subtracting a number of days. > Example query: > CREATE TABLE foo (bar DATE); > SELECT bar - 1 FROM foo; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3974) Convert some existing private data fields of AST nodes to be public
[ https://issues.apache.org/jira/browse/CALCITE-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Drew Schmitt updated CALCITE-3974: -- Summary: Convert some existing private data fields of AST nodes to be public (was: Add some accessors for Calcite AST nodes private data fields) > Convert some existing private data fields of AST nodes to be public > --- > > Key: CALCITE-3974 > URL: https://issues.apache.org/jira/browse/CALCITE-3974 > Project: Calcite > Issue Type: Improvement >Reporter: Drew Schmitt >Priority: Minor > > There are a few private fields in Calcite's AST nodes that would be easier to > access with an explicit getter, rather than using the getOperandList() method. > For example, SqlCreateFunction's name field is private, but can already be > access through getOperandList().get(0). We should add an explicit getName() > getter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3946) Add parser support for MULTISET/SET and VOLATILE modifiers in CREATE TABLE statements
[
https://issues.apache.org/jira/browse/CALCITE-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108675#comment-17108675
]
Drew Schmitt commented on CALCITE-3946:
---
Thanks for the feedback!
- I'm interested to see what the community decides on regarding babel vs.
server dependency. I agree that intuitively babel should take a dependency on
server. I've preemptively updated my PR to incorporate your changes in
3946-create-table. I can change to some other model if that's the consensus.
- Teradata vs. ANSI mode is controlled by the client. The mode changes the
behavior of a given query (e.g. defaulting to using MULTISET vs. SET when
unspecified). However, AFAIK it shouldn't impact the parsing or validation. As
such, we shouldn't need to provide a way to switch between modes in Calcite. I
can remove the comment altogether if it makes things more confusing.
- I've line-wrapped the long lines.
> Add parser support for MULTISET/SET and VOLATILE modifiers in CREATE TABLE
> statements
> -
>
> Key: CALCITE-3946
> URL: https://issues.apache.org/jira/browse/CALCITE-3946
> Project: Calcite
> Issue Type: Improvement
> Components: babel
>Affects Versions: 1.22.0
>Reporter: Drew Schmitt
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add support to Calcite's Babel parser for {{MULTISET}}/{{SET}} and
> {{VOLATILE}} modifiers in {{CREATE TABLE}} statements.
> The syntax for these statements is:
> {code:sql}
> CREATE TABLE [SET|MULTISET] [VOLATILE]
>[IF NOT EXISTS] ( , ...);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3987) Allow addition and subtraction operations between DATE and NUMERIC types.
[ https://issues.apache.org/jira/browse/CALCITE-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17104869#comment-17104869 ] Drew Schmitt commented on CALCITE-3987: --- Ok limiting to a specific conformance mode sounds reasonable. Is there an existing example I can follow which does this already? > Allow addition and subtraction operations between DATE and NUMERIC types. > - > > Key: CALCITE-3987 > URL: https://issues.apache.org/jira/browse/CALCITE-3987 > Project: Calcite > Issue Type: Improvement >Reporter: Drew Schmitt >Priority: Minor > > We should allow addition (PLUS operator) and subtraction (MINUS operator) > between DATE and NUMERIC types to be valid during the validation phase. > Downstream, the result of the operation can be interpreted differently > depending on the dialect. For example, some dialects would interpret any > arithmetic with a DATE as implying adding/subtracting a number of days. > Example query: > CREATE TABLE foo (bar DATE); > SELECT bar - 1 FROM foo; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3987) Allow addition and subtraction operations between DATE and NUMERIC types.
[ https://issues.apache.org/jira/browse/CALCITE-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17104683#comment-17104683 ] Drew Schmitt commented on CALCITE-3987: --- Teradata supports this syntax. > Allow addition and subtraction operations between DATE and NUMERIC types. > - > > Key: CALCITE-3987 > URL: https://issues.apache.org/jira/browse/CALCITE-3987 > Project: Calcite > Issue Type: Improvement >Reporter: Drew Schmitt >Priority: Minor > > We should allow addition (PLUS operator) and subtraction (MINUS operator) > between DATE and NUMERIC types to be valid during the validation phase. > Downstream, the result of the operation can be interpreted differently > depending on the dialect. For example, some dialects would interpret any > arithmetic with a DATE as implying adding/subtracting a number of days. > Example query: > CREATE TABLE foo (bar DATE); > SELECT bar - 1 FROM foo; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3987) Allow addition and subtraction operations between DATE and NUMERIC types.
Drew Schmitt created CALCITE-3987: - Summary: Allow addition and subtraction operations between DATE and NUMERIC types. Key: CALCITE-3987 URL: https://issues.apache.org/jira/browse/CALCITE-3987 Project: Calcite Issue Type: Improvement Reporter: Drew Schmitt We should allow addition (PLUS operator) and subtraction (MINUS operator) between DATE and NUMERIC types to be valid during the validation phase. Downstream, the result of the operation can be interpreted differently depending on the dialect. For example, some dialects would interpret any arithmetic with a DATE as implying adding/subtracting a number of days. Example query: CREATE TABLE foo (bar DATE); SELECT bar - 1 FROM foo; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3986) Provide config option to omit assigning an alias that is identical to its identifier.
Drew Schmitt created CALCITE-3986: - Summary: Provide config option to omit assigning an alias that is identical to its identifier. Key: CALCITE-3986 URL: https://issues.apache.org/jira/browse/CALCITE-3986 Project: Calcite Issue Type: Improvement Reporter: Drew Schmitt The current alias assignment logic with the SqlValidator config option identifierExpansion() set to true will eagerly try to choose an alias, even if the alias name ends up being the same as the identifier itself. For example, it will assign the alias "foo" for the table "foo". It's nice to have alias assignment, but making it identical to the identifier doesn't always provide a whole lot of value and can make queries more verbose than they need to be. Suggest we add another SqlValidator config option (defaulted to the current behavior) to allow a caller to disable alias assignment in the cases that it would be identical to the identifier. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3974) Add some accessors for Calcite AST nodes private data fields
[ https://issues.apache.org/jira/browse/CALCITE-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Drew Schmitt updated CALCITE-3974: -- Priority: Minor (was: Major) > Add some accessors for Calcite AST nodes private data fields > > > Key: CALCITE-3974 > URL: https://issues.apache.org/jira/browse/CALCITE-3974 > Project: Calcite > Issue Type: Improvement >Reporter: Drew Schmitt >Priority: Minor > > There are a few private fields in Calcite's AST nodes that would be easier to > access with an explicit getter, rather than using the getOperandList() method. > For example, SqlCreateFunction's name field is private, but can already be > access through getOperandList().get(0). We should add an explicit getName() > getter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3974) Add some accessors for Calcite AST nodes private data fields
Drew Schmitt created CALCITE-3974: - Summary: Add some accessors for Calcite AST nodes private data fields Key: CALCITE-3974 URL: https://issues.apache.org/jira/browse/CALCITE-3974 Project: Calcite Issue Type: Improvement Reporter: Drew Schmitt There are a few private fields in Calcite's AST nodes that would be easier to access with an explicit getter, rather than using the getOperandList() method. For example, SqlCreateFunction's name field is private, but can already be access through getOperandList().get(0). We should add an explicit getName() getter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3883) Multiple tests can fail if collection ordering is different than expected
Drew Schmitt created CALCITE-3883:
-
Summary: Multiple tests can fail if collection ordering is
different than expected
Key: CALCITE-3883
URL: https://issues.apache.org/jira/browse/CALCITE-3883
Project: Calcite
Issue Type: Bug
Reporter: Drew Schmitt
Multiple tests across at least two components (e.g. core and linq4j) can fail
if collection ordering (but not contents) is different than expected. Below are
a subset of the failing tests. In total, I'm seeing 21 failing tests in core
and 4 failing tests in linq4j.
For example, org.apache.calcite.test.SqlFunctionsTest's testMultiset:
FAILURE 0.1sec, org.apache.calcite.test.SqlFunctionsTest > testMultiset()
java.lang.AssertionError:
Expected: is <[b, e]>
but: was <[e, b]>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.calcite.test.SqlFunctionsTest.testMultiset(SqlFunctionsTest.java:906)
This failure is coming from:
assertThat(SqlFunctions.multisetExceptDistinct(abacee, addc),
is(Arrays.asList("b", "e")));
which is calling into the following function:
public static Collection multisetExceptDistinct(Collection c1,
Collection c2) {
final Set result = new HashSet<>(c1);
result.removeAll(c2);
return new ArrayList<>(result);
}
Another example is org.apache.calcite.linq4j.test.Linq4jTest's
testGroupByWithKeySelectorAndElementSelector:
FAILURE 0.0sec, org.apache.calcite.linq4j.test.Linq4jTest >
testGroupByWithKeySelectorAndElementSelector()
java.lang.AssertionError:
Expected: is "[10: Fred+Eric+Janet, 30: Bill]"
but: was "[30: Bill, 10: Fred+Eric+Janet]"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.calcite.linq4j.test.Linq4jTest.testGroupByWithKeySelectorAndElementSelector(Linq4jTest.java:1949)
This failure is generated from:
assertThat(s, is("[10: Fred+Eric+Janet, 30: Bill]"));
This behavior may have similarities with the issue reported in
https://issues.apache.org/jira/browse/CALCITE-3389.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
