[jira] [Commented] (CALCITE-4171) Support named parameters for table window functions
[
https://issues.apache.org/jira/browse/CALCITE-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177522#comment-17177522
]
Rui Wang commented on CALCITE-4171:
---
One question jumped into my mind: Is parameter name affected by
SqlParser.Config.caseSensitive()? Should it supposed to be?
I can give a test later after this PR is merged.
> Support named parameters for table window functions
> ---
>
> Key: CALCITE-4171
> URL: https://issues.apache.org/jira/browse/CALCITE-4171
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0, 1.24.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Supports window functions like named params style:
> {code:sql}
> select *
> from table(
> session(
> data => table Shipments,
> timecol => descriptor(rowtime),
> key => descriptor(orderId),
> size => INTERVAL '10' MINUTE))
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4171) Support named parameters for table window functions
[
https://issues.apache.org/jira/browse/CALCITE-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177521#comment-17177521
]
Julian Hyde commented on CALCITE-4171:
--
[~danny0405], I saw you added some mechanism to prevent functions from using
default values for parameters. Is this necessary? Is it not possible to make
the parameters not null and required, or something? At the very least, see if
you can make it mesh with the mechanism for using annotations to parameters
when UDFs are defined as Java functions.
> Support named parameters for table window functions
> ---
>
> Key: CALCITE-4171
> URL: https://issues.apache.org/jira/browse/CALCITE-4171
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0, 1.24.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Supports window functions like named params style:
> {code:sql}
> select *
> from table(
> session(
> data => table Shipments,
> timecol => descriptor(rowtime),
> key => descriptor(orderId),
> size => INTERVAL '10' MINUTE))
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3788) SqlValidatorImpl.registerOperandSubQueries should skip creating SCALAR_QUERY call when operand is a SqlSelect cause the SqlSelect does not return a scalar value
[
https://issues.apache.org/jira/browse/CALCITE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-3788.
-
Resolution: Duplicate
> SqlValidatorImpl.registerOperandSubQueries should skip creating SCALAR_QUERY
> call when operand is a SqlSelect cause the SqlSelect does not return a scalar
> value
>
>
> Key: CALCITE-3788
> URL: https://issues.apache.org/jira/browse/CALCITE-3788
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Rui Wang
>Priority: Major
>
> For a table function which uses named argument for a TABLE parameter:
> {code:sql}
> Select * From
> TABLE(TUMBLE(
>data => TABLE orders
>...
> )
> {code}
> The TABLE parameter will be wrapped by a SCALAR_QUERY call at this line:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L3067
> However, it is wrong because TABLE paramter is not a query that returns a
> scalar value.
> It cannot be solved by overriding SqlOperator.argumentMustBeScalar because
> named argument is a special operator that doesn't tied with other operators.
> One possible resolution is also check if operand is SqlSelect at
> SqlValidatorImpl.java#L3067.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4176) Key descriptor can be optional in SESSION table function
[ https://issues.apache.org/jira/browse/CALCITE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-4176: -- Description: In [1], people mentioned key descriptor might not be required for use cases in SESSION table function. For example, the SESSION table function can directly be applied on a data from a website. Technically there is still a key, but just all data have the same website key. There are three options to make key descriptor "optional" 1) make key descriptor optional. 2) accept empty descriptor. 3) descriptor becomes nullable. I am planning to try 1) first. [1]: https://issues.apache.org/jira/browse/CALCITE-3780?focusedCommentId=17166086=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17166086 > Key descriptor can be optional in SESSION table function > > > Key: CALCITE-4176 > URL: https://issues.apache.org/jira/browse/CALCITE-4176 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > In [1], people mentioned key descriptor might not be required for use cases > in SESSION table function. For example, the SESSION table function can > directly be applied on a data from a website. Technically there is still a > key, but just all data have the same website key. > There are three options to make key descriptor "optional" > 1) make key descriptor optional. > 2) accept empty descriptor. > 3) descriptor becomes nullable. > I am planning to try 1) first. > [1]: > https://issues.apache.org/jira/browse/CALCITE-3780?focusedCommentId=17166086=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17166086 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4176) Key descriptor can be optional in SESSION table function
[ https://issues.apache.org/jira/browse/CALCITE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177520#comment-17177520 ] Rui Wang commented on CALCITE-4176: --- Waiting for https://github.com/apache/calcite/pull/2103 > Key descriptor can be optional in SESSION table function > > > Key: CALCITE-4176 > URL: https://issues.apache.org/jira/browse/CALCITE-4176 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > In [1], people mentioned key descriptor might not be required for use cases > in SESSION table function. For example, the SESSION table function can > directly be applied on a data from a website. Technically there is still a > key, but just all data have the same website key. > There are three options to make key descriptor "optional" > 1) make key descriptor optional. > 2) accept empty descriptor. > 3) descriptor becomes nullable. > I am planning to try 1) first. > [1]: > https://issues.apache.org/jira/browse/CALCITE-3780?focusedCommentId=17166086=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17166086 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4176) Key descriptor can be optional in SESSION table function
Rui Wang created CALCITE-4176: - Summary: Key descriptor can be optional in SESSION table function Key: CALCITE-4176 URL: https://issues.apache.org/jira/browse/CALCITE-4176 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3780) SESSION Table-valued Function
[
https://issues.apache.org/jira/browse/CALCITE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177512#comment-17177512
]
Rui Wang commented on CALCITE-3780:
---
I will wait https://github.com/apache/calcite/pull/2103 be merged and then
draft the PR to make key descriptor optionally. #2103 is doing a big
refactoring.
> SESSION Table-valued Function
> -
>
> Key: CALCITE-3780
> URL: https://issues.apache.org/jira/browse/CALCITE-3780
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
> Fix For: 1.23.0
>
>
> We can create SESSION table-valued function to replace GROUP BY SESSION for
> inactive gap session functionality:
> {code:sql}
> SELECT *
> FROM TABLE SESSION (
> data => TABLE Bid ,
> timecol => DESCRIPTOR ( bidtime ) ,
> keycol => DESCRIPTOR(key),
> inactive_gap => INTERVAL '10' MINUTES )
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4174) avatica-go should handle complex/long URLs
[ https://issues.apache.org/jira/browse/CALCITE-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-4174: Fix Version/s: (was: avatica-1.18.0) avatica-go-5.1.0 > avatica-go should handle complex/long URLs > -- > > Key: CALCITE-4174 > URL: https://issues.apache.org/jira/browse/CALCITE-4174 > Project: Calcite > Issue Type: Improvement > Components: avatica-go >Reporter: Josiah Goodson >Assignee: Josiah Goodson >Priority: Major > Fix For: avatica-go-5.1.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > The current avatica-go driver assumes the full URL path is the schema name. > This is incorrect for some deployments - for example, using a proxy. > Current behavior: > dsn = "http://host.com/service/proxy/schema; > conf.schema = "service/proxy/schema" > Expected behavior: > dsn = "http://host.com/service/proxy/schema; > conf.schema = "schema" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4175) Add ability to create a connection and DSN from a Config
[ https://issues.apache.org/jira/browse/CALCITE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-4175: Fix Version/s: (was: avatica-1.18.0) avatica-go-5.1.0 > Add ability to create a connection and DSN from a Config > > > Key: CALCITE-4175 > URL: https://issues.apache.org/jira/browse/CALCITE-4175 > Project: Calcite > Issue Type: Improvement > Components: avatica-go >Reporter: Josiah Goodson >Assignee: Josiah Goodson >Priority: Major > Fix For: avatica-go-5.1.0 > > > Currently the avatica-go driver requires the user to specify a DSN to open > connections. A config is then generated from this DSN. > Other similar projects > ([go-sql-driver/mysql|https://godoc.org/github.com/go-sql-driver/mysql#Config.FormatDSN]) > allow you to create a DSN from a config supplied in a struct. > This issue covers the ability to create a connection and DSN from a Config -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4174) avatica-go should handle complex/long URLs
[ https://issues.apache.org/jira/browse/CALCITE-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-4174: Fix Version/s: avatica-1.18.0 > avatica-go should handle complex/long URLs > -- > > Key: CALCITE-4174 > URL: https://issues.apache.org/jira/browse/CALCITE-4174 > Project: Calcite > Issue Type: Improvement > Components: avatica-go >Reporter: Josiah Goodson >Assignee: Josiah Goodson >Priority: Major > Fix For: avatica-1.18.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > The current avatica-go driver assumes the full URL path is the schema name. > This is incorrect for some deployments - for example, using a proxy. > Current behavior: > dsn = "http://host.com/service/proxy/schema; > conf.schema = "service/proxy/schema" > Expected behavior: > dsn = "http://host.com/service/proxy/schema; > conf.schema = "schema" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4175) Add ability to create a connection and DSN from a Config
[ https://issues.apache.org/jira/browse/CALCITE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-4175: Fix Version/s: avatica-1.18.0 > Add ability to create a connection and DSN from a Config > > > Key: CALCITE-4175 > URL: https://issues.apache.org/jira/browse/CALCITE-4175 > Project: Calcite > Issue Type: Improvement > Components: avatica-go >Reporter: Josiah Goodson >Assignee: Josiah Goodson >Priority: Major > Fix For: avatica-1.18.0 > > > Currently the avatica-go driver requires the user to specify a DSN to open > connections. A config is then generated from this DSN. > Other similar projects > ([go-sql-driver/mysql|https://godoc.org/github.com/go-sql-driver/mysql#Config.FormatDSN]) > allow you to create a DSN from a config supplied in a struct. > This issue covers the ability to create a connection and DSN from a Config -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4175) Add ability to create a connection and DSN from a Config
[ https://issues.apache.org/jira/browse/CALCITE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang reassigned CALCITE-4175: --- Assignee: Josiah Goodson (was: Francis Chuang) > Add ability to create a connection and DSN from a Config > > > Key: CALCITE-4175 > URL: https://issues.apache.org/jira/browse/CALCITE-4175 > Project: Calcite > Issue Type: Improvement > Components: avatica-go >Reporter: Josiah Goodson >Assignee: Josiah Goodson >Priority: Major > > Currently the avatica-go driver requires the user to specify a DSN to open > connections. A config is then generated from this DSN. > Other similar projects > ([go-sql-driver/mysql|https://godoc.org/github.com/go-sql-driver/mysql#Config.FormatDSN]) > allow you to create a DSN from a config supplied in a struct. > This issue covers the ability to create a connection and DSN from a Config -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4174) avatica-go should handle complex/long URLs
[ https://issues.apache.org/jira/browse/CALCITE-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang reassigned CALCITE-4174: --- Assignee: Josiah Goodson (was: Francis Chuang) > avatica-go should handle complex/long URLs > -- > > Key: CALCITE-4174 > URL: https://issues.apache.org/jira/browse/CALCITE-4174 > Project: Calcite > Issue Type: Improvement > Components: avatica-go >Reporter: Josiah Goodson >Assignee: Josiah Goodson >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > The current avatica-go driver assumes the full URL path is the schema name. > This is incorrect for some deployments - for example, using a proxy. > Current behavior: > dsn = "http://host.com/service/proxy/schema; > conf.schema = "service/proxy/schema" > Expected behavior: > dsn = "http://host.com/service/proxy/schema; > conf.schema = "schema" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4175) Add ability to create a connection and DSN from a Config
Josiah Goodson created CALCITE-4175: --- Summary: Add ability to create a connection and DSN from a Config Key: CALCITE-4175 URL: https://issues.apache.org/jira/browse/CALCITE-4175 Project: Calcite Issue Type: Improvement Components: avatica-go Reporter: Josiah Goodson Assignee: Francis Chuang Currently the avatica-go driver requires the user to specify a DSN to open connections. A config is then generated from this DSN. Other similar projects ([go-sql-driver/mysql|https://godoc.org/github.com/go-sql-driver/mysql#Config.FormatDSN]) allow you to create a DSN from a config supplied in a struct. This issue covers the ability to create a connection and DSN from a Config -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-2854) Codegen compile error when implementing unary minus function with data type BigDecimal
[
https://issues.apache.org/jira/browse/CALCITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-2854:
---
Fix Version/s: 1.25.0
> Codegen compile error when implementing unary minus function with data type
> BigDecimal
> --
>
> Key: CALCITE-2854
> URL: https://issues.apache.org/jira/browse/CALCITE-2854
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.18.0
>Reporter: Lai Zhou
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.25.0
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> case:
> {code:java}
> @Test public void test() throws Exception {
> final String cr = "create table t (a DECIMAL)";
> final String se = "select -a as aa from t";
> Connection c = connect();
> Statement s = c.createStatement();
> s.execute(cr);
> s.executeQuery(se);
> }
> {code}
> error msg:
> {code:java}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 21, Column
> 71: Object of type "java.math.BigDecimal" cannot be converted to a numeric
> type
> {code}
> {code:java}
> public Object current() {
> final java.math.BigDecimal current = inputEnumerator.current() == null ?
> (java.math.BigDecimal) null :
> org.apache.calcite.runtime.SqlFunctions.toBigDecimal(inputEnumerator.current());
> return current == null ? (java.math.BigDecimal) null : - current;
> }
> {code}
> `- current` is not right ,we'd better constructor a new BigDecimal object to
> to replace this code snippet，like
> {code:java}
> return current == null ? (java.math.BigDecimal) null :
> SqlFunctions.negativeDecimal(current);
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4172) SqlValidatorImpl.validateGroupClause should expand identifiers before resolving them against the catalog
[
https://issues.apache.org/jira/browse/CALCITE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177288#comment-17177288
]
James Starr commented on CALCITE-4172:
--
[~julianhyde], what particular formatting do want be clean up? Would you like
me to move the test into another class? Any preference on which?
I believe that expand was called before other call to the catalog was initial
at some point in time, but not enforce. And then derived types was added or
expanded, and not much thought was put into where exactly it was called, and
this is simply fixing the over site. InferTypes is calling the catalog to get
the type of the field so it can infer it
To clarify, I want to do this because I want a relatively clean api to rewrite
column references.
> SqlValidatorImpl.validateGroupClause should expand identifiers before
> resolving them against the catalog
>
>
> Key: CALCITE-4172
> URL: https://issues.apache.org/jira/browse/CALCITE-4172
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: James Starr
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am attempt to support a Linq style syntax where you can 'dot' into a
> complex element. In order to do this I am attempt to use
> SqlValidatorImpl.expand and related functions to rewrite the columnar
> identifiers before they are validated.
> SqlValidatorImpl.validateGroupClause calls SqlValidatorImpl.inferUnknownTypes
> which attempts to resolve the identifiers against the catalog. Every where
> else that I am aware of first expands the identifier if configured to before
> resolving.
> SqlValidatorImpl.validateGroupClause immediately after calling
> inferUnknownTypes expands the identifiers.
> {code:java}
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4470)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4470)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:364)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5220)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5183)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:344) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1602)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1587)
> at
> org.apache.calcite.sql.type.InferTypes$1.inferOperandTypes(InferTypes.java:52)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1773)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1738)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateGroupClause(SqlValidatorImpl.java:3576)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3201)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:943)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:924)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:226){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4171) Support named parameters for table window functions
[
https://issues.apache.org/jira/browse/CALCITE-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177272#comment-17177272
]
Julian Hyde commented on CALCITE-4171:
--
Sorry; as I said, I didn't see any tests, but that doesn't mean there weren't
any. I should have said that I didn't look very hard.
> Support named parameters for table window functions
> ---
>
> Key: CALCITE-4171
> URL: https://issues.apache.org/jira/browse/CALCITE-4171
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0, 1.24.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Supports window functions like named params style:
> {code:sql}
> select *
> from table(
> session(
> data => table Shipments,
> timecol => descriptor(rowtime),
> key => descriptor(orderId),
> size => INTERVAL '10' MINUTE))
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4172) SqlValidatorImpl.validateGroupClause should expand identifiers before resolving them against the catalog
[
https://issues.apache.org/jira/browse/CALCITE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17177261#comment-17177261
]
Julian Hyde commented on CALCITE-4172:
--
I have trouble getting my head around the cause of this, but if it does not
break anything else I have no problem with it.
The PR will need a little cleanup (formatting). Also, I'm not a fan of small
standalone tests.
> SqlValidatorImpl.validateGroupClause should expand identifiers before
> resolving them against the catalog
>
>
> Key: CALCITE-4172
> URL: https://issues.apache.org/jira/browse/CALCITE-4172
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: James Starr
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am attempt to support a Linq style syntax where you can 'dot' into a
> complex element. In order to do this I am attempt to use
> SqlValidatorImpl.expand and related functions to rewrite the columnar
> identifiers before they are validated.
> SqlValidatorImpl.validateGroupClause calls SqlValidatorImpl.inferUnknownTypes
> which attempts to resolve the identifiers against the catalog. Every where
> else that I am aware of first expands the identifier if configured to before
> resolving.
> SqlValidatorImpl.validateGroupClause immediately after calling
> inferUnknownTypes expands the identifiers.
> {code:java}
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4470)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4470)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:364)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5220)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5183)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:344) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1602)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1587)
> at
> org.apache.calcite.sql.type.InferTypes$1.inferOperandTypes(InferTypes.java:52)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1773)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1738)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateGroupClause(SqlValidatorImpl.java:3576)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3201)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:943)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:924)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:226){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4174) avatica-go should handle complex/long URLs
Josiah Goodson created CALCITE-4174: --- Summary: avatica-go should handle complex/long URLs Key: CALCITE-4174 URL: https://issues.apache.org/jira/browse/CALCITE-4174 Project: Calcite Issue Type: Improvement Components: avatica-go Reporter: Josiah Goodson Assignee: Francis Chuang The current avatica-go driver assumes the full URL path is the schema name. This is incorrect for some deployments - for example, using a proxy. Current behavior: dsn = "http://host.com/service/proxy/schema; conf.schema = "service/proxy/schema" Expected behavior: dsn = "http://host.com/service/proxy/schema; conf.schema = "schema" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4173) Add internal SEARCH operator and Sarg literal, replacing use of IN in RexCall
[
https://issues.apache.org/jira/browse/CALCITE-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-4173:
Assignee: Julian Hyde
> Add internal SEARCH operator and Sarg literal, replacing use of IN in RexCall
> -
>
> Key: CALCITE-4173
> URL: https://issues.apache.org/jira/browse/CALCITE-4173
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> Add internal SEARCH operator and Sarg literal, replacing use of IN in RexCall.
> Recently we started to allow IN in RexCalls to represent lists of constant
> values; previously it had only been allowed in SqlCall. The use is confusing,
> because a RexSubQuery is a sub-class of RexCall that may also use IN as its
> operator.
> More important, we would like to be able to represent more general search
> arguments in a single RexCall. Examples:
> * {{x BETWEEN 3 AND 10}}
> * {{x > 3 AND x <= 10}}
> * {{x NOT BETWEEN 3 AND 10}}
> * {{x IS NULL OR x BETWEEN 3 AND 100 AND x != 50 OR x IN (200, 300, 400)}}
> * {{x > 5 AND x < 10 AND x IN (3, 8, 10, 20)}}
> All of these can be converted to sets of ranges, where each range has a lower
> or upper bound (or both), bounds can be open or closed, plus a flag to say
> whether NULL is an allowed value. Guava's RangeSet is an efficient
> implementation of range sets.
> This change would create a new class {{Sarg}} to represent a range set as a
> literal. The new internal SEARCH operator tests whether an operand belongs to
> the range set.
> A RexCall to SEARCH is converted back to SQL, typically an IN or OR.
> This change would obsolete the use of IN in {{RexCall}} to represent a fixed
> list of values. (This is a breaking change, but when we first allowed IN in
> {{RexCall}}, in CALCITE-2444, it was only intended to be for
> {{RelToSqlConverter}}. Most people still believe that [IN is not
> allowed|https://lists.apache.org/thread.html/e1c5d56ecca7c1bc3608344ceac9b209bb8100fbca1c1928feb9cce7%40%3Cdev.calcite.apache.org%3E].)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4173) Add internal SEARCH operator and Sarg literal, replacing use of IN in RexCall
Julian Hyde created CALCITE-4173:
Summary: Add internal SEARCH operator and Sarg literal, replacing
use of IN in RexCall
Key: CALCITE-4173
URL: https://issues.apache.org/jira/browse/CALCITE-4173
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Add internal SEARCH operator and Sarg literal, replacing use of IN in RexCall.
Recently we started to allow IN in RexCalls to represent lists of constant
values; previously it had only been allowed in SqlCall. The use is confusing,
because a RexSubQuery is a sub-class of RexCall that may also use IN as its
operator.
More important, we would like to be able to represent more general search
arguments in a single RexCall. Examples:
* {{x BETWEEN 3 AND 10}}
* {{x > 3 AND x <= 10}}
* {{x NOT BETWEEN 3 AND 10}}
* {{x IS NULL OR x BETWEEN 3 AND 100 AND x != 50 OR x IN (200, 300, 400)}}
* {{x > 5 AND x < 10 AND x IN (3, 8, 10, 20)}}
All of these can be converted to sets of ranges, where each range has a lower
or upper bound (or both), bounds can be open or closed, plus a flag to say
whether NULL is an allowed value. Guava's RangeSet is an efficient
implementation of range sets.
This change would create a new class {{Sarg}} to represent a range set as a
literal. The new internal SEARCH operator tests whether an operand belongs to
the range set.
A RexCall to SEARCH is converted back to SQL, typically an IN or OR.
This change would obsolete the use of IN in {{RexCall}} to represent a fixed
list of values. (This is a breaking change, but when we first allowed IN in
{{RexCall}}, in CALCITE-2444, it was only intended to be for
{{RelToSqlConverter}}. Most people still believe that [IN is not
allowed|https://lists.apache.org/thread.html/e1c5d56ecca7c1bc3608344ceac9b209bb8100fbca1c1928feb9cce7%40%3Cdev.calcite.apache.org%3E].)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3916) Support cascades style top-down driven rule apply
[
https://issues.apache.org/jira/browse/CALCITE-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176821#comment-17176821
]
Ruben Q L commented on CALCITE-3916:
Thanks [~hyuan]! That solves the {{ClassCastException}} issue. Sorry, my bad, I
misunderstood the {{passThrough}} contract, I thought that, apart from
collation, I had to consider convention too. But you are right, ignoring the
convention fixed the problem.
> Support cascades style top-down driven rule apply
> -
>
> Key: CALCITE-3916
> URL: https://issues.apache.org/jira/browse/CALCITE-3916
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Assignee: Jinpeng Wu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.24.0
>
> Time Spent: 15.5h
> Remaining Estimate: 0h
>
> Apply rules by leaf RelSet -> root RelSet order. For every RelNode in a
> RelSet, rule is matched and applied sequentially. No RuleQueue and
> DeferringRuleCall is needed anymore. This will make space pruning and rule
> mutual exclusivity check possible.
> Rule that use AbstractConverter as operand is an exception, to keep backward
> compatibility, this kind of rule still needs top-down apply.
> This should be done after CALCITE-3896.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
