[jira] [Commented] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[ https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694318#comment-16694318 ] Jark Wu commented on CALCITE-1912: -- Hi [~julianhyde], do you have time to have a look at the PR again? > Support "FOR SYSTEM_TIME AS OF" in regular queries > -- > > Key: CALCITE-1912 > URL: https://issues.apache.org/jira/browse/CALCITE-1912 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" > in Calcite to retrieve table contents as of a given point in time. > [1] > https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[ https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16735430#comment-16735430 ] Jark Wu commented on CALCITE-1912: -- Hi [~francischuang], [~julianhyde] sorry to bother you. Is there any plan for this issue ? > Support "FOR SYSTEM_TIME AS OF" in regular queries > -- > > Key: CALCITE-1912 > URL: https://issues.apache.org/jira/browse/CALCITE-1912 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > > As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" > in Calcite to retrieve table contents as of a given point in time. > [1] > https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[ https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16735448#comment-16735448 ] Jark Wu commented on CALCITE-1912: -- Thanks [~francischuang] , I will rebase and fix it today. > Support "FOR SYSTEM_TIME AS OF" in regular queries > -- > > Key: CALCITE-1912 > URL: https://issues.apache.org/jira/browse/CALCITE-1912 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > > As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" > in Calcite to retrieve table contents as of a given point in time. > [1] > https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[ https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16736576#comment-16736576 ] Jark Wu commented on CALCITE-1912: -- I have rebased the PR, and all tests passed. Welcome to review. > Support "FOR SYSTEM_TIME AS OF" in regular queries > -- > > Key: CALCITE-1912 > URL: https://issues.apache.org/jira/browse/CALCITE-1912 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > > As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" > in Calcite to retrieve table contents as of a given point in time. > [1] > https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[ https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jark Wu updated CALCITE-1912: - Fix Version/s: 1.19.0 > Support "FOR SYSTEM_TIME AS OF" in regular queries > -- > > Key: CALCITE-1912 > URL: https://issues.apache.org/jira/browse/CALCITE-1912 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Priority: Major > Labels: pull-request-available > Fix For: 1.19.0 > > > As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" > in Calcite to retrieve table contents as of a given point in time. > [1] > https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3271) TVF windowing and EMIT syntax support in Calcite
[ https://issues.apache.org/jira/browse/CALCITE-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911978#comment-16911978 ] Jark Wu commented on CALCITE-3271: -- EMIT is very helpful to early fire windows and trigger on late records. We also have implemented a dialect in Blink SQL[1] and it is great to have EMIT syntax in Calcite. Looking forward to it. And glad to help if possible. [1]: http://blink.flink-china.org/dev/table/sql.html#emit-strategy > TVF windowing and EMIT syntax support in Calcite > > > Key: CALCITE-3271 > URL: https://issues.apache.org/jira/browse/CALCITE-3271 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.20.0 >Reporter: Danny Chan >Assignee: Danny Chan >Priority: Major > > Copied from the mailing list: > Calcite has not implemented the syntax in that paper. I would support an > effort to add it (unsurprising, since I am a co-author of that paper). > EMIT STREAM is equivalent to the current SELECT STREAM syntax. > There is no equivalent in current Calcite of the EMIT AFTER WATERMARK, or > EMIT STREAM AFTER DELAY. > HOP, TUMBLE and SESSION are supported in Calcite’s SQL parser, but following > the paper would be replaced with a table function call. We could need to add > HOP, TUMBLE and SESSION table functions. We would also need to make the > system aware of how watermarks flow through these table functions (an area > that the paper does not go into). > Julian -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-4282) Promote the window table functions window attribute data type with precision 3
[
https://issues.apache.org/jira/browse/CALCITE-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17204446#comment-17204446
]
Jark Wu commented on CALCITE-4282:
--
Hi [~danny0405], shouldn't the TIMESTAMP precision of window_start/window_end
to be align with the rowtime precision (e.g. {{ReturnTypes.ARG0}})? Just like
the TUMBLE_START, TUMBL_END.
I'm wondering why we force a precision here.
> Promote the window table functions window attribute data type with precision 3
> --
>
> Key: CALCITE-4282
> URL: https://issues.apache.org/jira/browse/CALCITE-4282
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.25.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now the {{window_start}} and {{window_end}} has a type of a Timestamp with
> default system precision. But, actually, many DB vendors has default
> precision as 6 (which is also defined in the SQL standard).
> We better promote the precision to 3 because:
> 1. For windowing, time unit as millisecond is enough
> 2. Make the precision deterministic instead of overriding by each engine's
> default one
--
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&focusedCommentId=17213566#comment-17213566
]
Jark Wu commented on CALCITE-3780:
--
Hi all, what's the plan to support PARTITION BY syntax for SESSION window? Do
we have an issue to track this?
> 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] [Commented] (CALCITE-3780) SESSION Table-valued Function
[
https://issues.apache.org/jira/browse/CALCITE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213578#comment-17213578
]
Jark Wu commented on CALCITE-3780:
--
Hi [~amaliujia], I just think the PARTITION BY clause is more SQL standard
compliant. Because the input table of SESSION window PTF is SET semantic and
data needs to be partitioned, PARTITION BY clause is introduced in SQL standard
on this purpose.
> 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] [Commented] (CALCITE-3780) SESSION Table-valued Function
[
https://issues.apache.org/jira/browse/CALCITE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213582#comment-17213582
]
Jark Wu commented on CALCITE-3780:
--
This can also help the optimizer know how to add an {{Exchange}} RelNode.
> 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] [Commented] (CALCITE-4337) Supports PARTITION BY clause for table function table argument
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214373#comment-17214373
]
Jark Wu commented on CALCITE-4337:
--
I dont' think SESSION window TVF must be used with GROUP BY, they should be
decoupled. A SESSION window can be used alone (just generate window columns) or
be used with other operators, in this case, the optimizer don't know what the
{{Exchange}} should be and how to partition data.
> Supports PARTITION BY clause for table function table argument
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Fix For: 1.27.0
>
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4396) Allows table valued functions of FROM and JOIN context without TABLE clause
[
https://issues.apache.org/jira/browse/CALCITE-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230510#comment-17230510
]
Jark Wu commented on CALCITE-4396:
--
+1 for this.
> Allows table valued functions of FROM and JOIN context without TABLE clause
> ---
>
> Key: CALCITE-4396
> URL: https://issues.apache.org/jira/browse/CALCITE-4396
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Fix For: 1.27.0
>
>
> In current code base, user can use a table valued function mainly for 2 kinds
> of SQL statements:
> {code:sql}
> -- select from the table valued function directly
> SELECT ... FROM TABLE(my_tvf(...));
> -- join the table valued function with LATERAL keyword
> ... t1 JOIN LATERAL TABLE(my_tvf(...)) ON ...
> {code}
> While since version 12.1+, Oracle supports syntax without TABLE keyword, thus
> you can write SQL as following[1]:
> {code:sql}
> -- select from the table valued function directly
> SELECT ... FROM my_tvf(...);
> -- join the table valued function with LATERAL keyword
> ... t1 JOIN my_tvf(...) ON ...
> {code}
> SQL-SERVER also allows select from the table valued function directly without
> the explicit TABLE keyword, but they need the CROSS APPLY clause for table
> and function join. [2]
> We already had a discussion on the DEV mailing list, see [3].
> I propose to support the Oracle style table valued function syntax: to omit
> the TABLE keyword because the syntax is straight-forward and concise.
> Of course, this syntax is only valid under Oracle SQL conformance.
> [1]
> https://livesql.oracle.com/apex/livesql/file/tutorial_GSOTSK8FWLYZOG5CJJ9KPX7RX.html
> [2]
> https://docs.microsoft.com/en-us/sql/relational-databases/user-defined-functions/create-user-defined-functions-database-engine?view=sql-server-ver15#TVF
> [3]
> https://lists.apache.org/x/thread.html/ra98db08e280ddd9adeef62f456f61aedfdf7756e215cb4d66e2a52c9@%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4508) Related to FLINK-21162,SQL optimization in OR syntax
[
https://issues.apache.org/jira/browse/CALCITE-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288783#comment-17288783
]
Jark Wu commented on CALCITE-4508:
--
This is a duplicate issue of CALCITE-4507, and I agree CALCITE-4446 can also
fix this problem.
> Related to FLINK-21162,SQL optimization in OR syntax
>
>
> Key: CALCITE-4508
> URL: https://issues.apache.org/jira/browse/CALCITE-4508
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.26.0
> Environment: flink-1.12,flink1.13
>Reporter: WeiNan Zhao
>Priority: Major
>
> [flink-table/flink-table-planner-blink/src/main/java/org/apache/calcite/rex/RexSimplify.java|https://github.com/apache/flink/pull/14872/files#diff-f13aa38a0e8d4eb656016353b2da73c4d53e9898098a5c497219829c1401c48e]
> linenum:2673
> case IS_NULL:
> {color:#ff}/** {color}
> {color:#ff}* when is_null in OR operate ,if change to search('',null)
> there was a major mistake, {color}
> {color:#ff}* because search has three return values
> (true,false,null),but OR Operate only {color}
> {color:#ff}* can return true or false,so wo can't change is_null or ...
> to search('',null); {color}
> {color:#ff}*/ {color}
> if (negate) \{ return false; }
> final RexNode arg = ((RexCall) e).operands.get(0);
> {color:#ffab00}return accept1( arg, e.getKind(),
> rexBuilder.makeNullLiteral(arg.getType()), newTerms);
> {color}{color:#4c9aff}It should not be converted here{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4545) Unparse a new function of FUNCTION_ID syntax will be quoted
Jark Wu created CALCITE-4545:
Summary: Unparse a new function of FUNCTION_ID syntax will be
quoted
Key: CALCITE-4545
URL: https://issues.apache.org/jira/browse/CALCITE-4545
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Jark Wu
Fix For: 1.27.0, 1.26.0
In Flink, we would like to introduce some new functions of FUNCTION_ID syntax,
e.g. {{CURRENT_ROW_TIMESTAMP}}. However, when unparsing this new function, we
will get the quoted string {{`CURRENT_ROW_TIMESTAMP`}} which can't be executed
anymore, because Calcite think it is a column reference.
The root cause of it is {{org.apache.calcite.sql.SqlIdentifier#unparse}} calls
{{org.apache.calcite.sql.SqlUtil#unparseSqlIdentifierSyntax}} where it uses a
static Calcite {{SqlStdOperatorTable.instance()}} instead of a user-defined
operator table. Therefore, it thinks it's not a sql function and unparse it
with quotes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4545) Unparse a new function of FUNCTION_ID syntax will be quoted
[
https://issues.apache.org/jira/browse/CALCITE-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306773#comment-17306773
]
Jark Wu commented on CALCITE-4545:
--
The {{CURRENT_ROW_TIMESTAMP}} in {{SELECT CURRENT_ROW_TIMESTAMP FROM T}} is
parsed into a {{SqlIdentifier}} instead of {{SqlCall}}. I guess the parser also
don't know whether it is a function call during parsing.
> Unparse a new function of FUNCTION_ID syntax will be quoted
> ---
>
> Key: CALCITE-4545
> URL: https://issues.apache.org/jira/browse/CALCITE-4545
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jark Wu
>Priority: Major
> Fix For: 1.26.0, 1.27.0
>
>
> In Flink, we would like to introduce some new functions of FUNCTION_ID
> syntax, e.g. {{CURRENT_ROW_TIMESTAMP}}. However, when unparsing this new
> function, we will get the quoted string {{`CURRENT_ROW_TIMESTAMP`}} which
> can't be executed anymore, because Calcite think it is a column reference.
> The root cause of it is {{org.apache.calcite.sql.SqlIdentifier#unparse}}
> calls {{org.apache.calcite.sql.SqlUtil#unparseSqlIdentifierSyntax}} where it
> uses a static Calcite {{SqlStdOperatorTable.instance()}} instead of a
> user-defined operator table. Therefore, it thinks it's not a sql function and
> unparse it with quotes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4545) Unparse a new function of FUNCTION_ID syntax will be quoted
[
https://issues.apache.org/jira/browse/CALCITE-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jark Wu updated CALCITE-4545:
-
Fix Version/s: (was: 1.27.0)
(was: 1.26.0)
> Unparse a new function of FUNCTION_ID syntax will be quoted
> ---
>
> Key: CALCITE-4545
> URL: https://issues.apache.org/jira/browse/CALCITE-4545
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jark Wu
>Priority: Major
>
> In Flink, we would like to introduce some new functions of FUNCTION_ID
> syntax, e.g. {{CURRENT_ROW_TIMESTAMP}}. However, when unparsing this new
> function, we will get the quoted string {{`CURRENT_ROW_TIMESTAMP`}} which
> can't be executed anymore, because Calcite think it is a column reference.
> The root cause of it is {{org.apache.calcite.sql.SqlIdentifier#unparse}}
> calls {{org.apache.calcite.sql.SqlUtil#unparseSqlIdentifierSyntax}} where it
> uses a static Calcite {{SqlStdOperatorTable.instance()}} instead of a
> user-defined operator table. Therefore, it thinks it's not a sql function and
> unparse it with quotes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3476) ParameterScope should override resolveColumn interface
Jark Wu created CALCITE-3476:
Summary: ParameterScope should override resolveColumn interface
Key: CALCITE-3476
URL: https://issues.apache.org/jira/browse/CALCITE-3476
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.21.0
Reporter: Jark Wu
I want to validate a SqlNode expression and find this interface
{{SqlValidator.validateParameterizedExpression(SqlNode topNode, Map nameToTypeMap)}}. The SqlNode expression is {{c + 1}}, and the
{{namedToTypeMap}} is {{c -> TIMESTAMP(3)}}. However, it throws following
exception.
After some debug, I find that the {{ParameterScope}} accepts {{namedToTypeMap}}
but never use it. We can fix this by overriding {{resolveColumn}} and lookup in
the map.
{code:java}
@Override
public RelDataType resolveColumn(String name, SqlNode ctx) {
return nameToTypeMap.get(name);
}
{code}
Exception stack:
{code:text}
org.apache.calcite.runtime.CalciteContextException: At line 5, column 31:
Unknown identifier 'c'
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:463)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:834)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:819)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4867)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5693)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:317)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
at
org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:593)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:237)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:219)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5626)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:236)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5330)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:940)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateParameterizedExpression(SqlValidatorImpl.java:927)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.lambda$createTableSchema$4(SqlToOperationConverter.java:236)
at java.util.Optional.ifPresent(Optional.java:159)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.createTableSchema(SqlToOperationConverter.java:232)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.convertCreateTable(SqlToOperationConverter.java:126)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.convert(SqlToOperationConverter.java:98)
at
org.apache.flink.table.sqlexec.SqlToOperationConverterTest.testCreateTableWithWatermark(SqlToOperationConverterTest.java:213)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:
[jira] [Updated] (CALCITE-3476) ParameterScope should override resolveColumn interface
[
https://issues.apache.org/jira/browse/CALCITE-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jark Wu updated CALCITE-3476:
-
Description:
I want to validate a SqlNode expression and find this interface
{{SqlValidator.validateParameterizedExpression(SqlNode topNode, Map nameToTypeMap)}}. The SqlNode expression is {{c + 1}}, and the
{{namedToTypeMap}} is {{c -> TIMESTAMP(3)}}. However, it throws following
exception.
After some debug, I find that the {{ParameterScope}} accepts {{namedToTypeMap}}
but never use it. We can fix this by overriding {{resolveColumn}} and lookup in
the map.
{code:java}
@Override
public RelDataType resolveColumn(String name, SqlNode ctx) {
return nameToTypeMap.get(name);
}
{code}
Exception stack:
{code}
org.apache.calcite.runtime.CalciteContextException: At line 5, column 31:
Unknown identifier 'c'
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:463)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:834)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:819)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4867)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5693)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:317)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
at
org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:593)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:237)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:219)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5626)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:236)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5330)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:940)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateParameterizedExpression(SqlValidatorImpl.java:927)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.lambda$createTableSchema$4(SqlToOperationConverter.java:236)
at java.util.Optional.ifPresent(Optional.java:159)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.createTableSchema(SqlToOperationConverter.java:232)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.convertCreateTable(SqlToOperationConverter.java:126)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.convert(SqlToOperationConverter.java:98)
at
org.apache.flink.table.sqlexec.SqlToOperationConverterTest.testCreateTableWithWatermark(SqlToOperationConverterTest.java:213)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
[jira] [Updated] (CALCITE-3476) ParameterScope should override resolveColumn interface
[
https://issues.apache.org/jira/browse/CALCITE-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jark Wu updated CALCITE-3476:
-
Description:
I want to validate a SqlNode expression and find this interface
{{SqlValidator.validateParameterizedExpression(SqlNode topNode, Map nameToTypeMap)}}. The SqlNode expression is {{c + 1}}, and the
{{namedToTypeMap}} is {{c -> TIMESTAMP(3)}}. However, it throws following
exception.
After some debug, I found that the {{ParameterScope}} accepts
{{namedToTypeMap}} but never use it. We can fix this by overriding
{{resolveColumn}} and lookup in the map.
{code:java}
@Override
public RelDataType resolveColumn(String name, SqlNode ctx) {
return nameToTypeMap.get(name);
}
{code}
Exception stack:
{code}
org.apache.calcite.runtime.CalciteContextException: At line 5, column 31:
Unknown identifier 'c'
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:463)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:834)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:819)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4867)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5693)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:317)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
at
org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:593)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:237)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:219)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5626)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:236)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5330)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:940)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateParameterizedExpression(SqlValidatorImpl.java:927)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.lambda$createTableSchema$4(SqlToOperationConverter.java:236)
at java.util.Optional.ifPresent(Optional.java:159)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.createTableSchema(SqlToOperationConverter.java:232)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.convertCreateTable(SqlToOperationConverter.java:126)
at
org.apache.flink.table.planner.operations.SqlToOperationConverter.convert(SqlToOperationConverter.java:98)
at
org.apache.flink.table.sqlexec.SqlToOperationConverterTest.testCreateTableWithWatermark(SqlToOperationConverterTest.java:213)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
[jira] [Commented] (CALCITE-3476) ParameterScope should override resolveColumn interface
[
https://issues.apache.org/jira/browse/CALCITE-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969941#comment-16969941
]
Jark Wu commented on CALCITE-3476:
--
Hi [~yanlin-Lynn], I'm already working on it. Will prepare a pull request soon.
> ParameterScope should override resolveColumn interface
> --
>
> Key: CALCITE-3476
> URL: https://issues.apache.org/jira/browse/CALCITE-3476
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Jark Wu
>Priority: Major
>
> I want to validate a SqlNode expression and find this interface
> {{SqlValidator.validateParameterizedExpression(SqlNode topNode, Map RelDataType> nameToTypeMap)}}. The SqlNode expression is {{c + 1}}, and the
> {{namedToTypeMap}} is {{c -> TIMESTAMP(3)}}. However, it throws following
> exception.
> After some debug, I found that the {{ParameterScope}} accepts
> {{namedToTypeMap}} but never use it. We can fix this by overriding
> {{resolveColumn}} and lookup in the map.
> {code:java}
> @Override
> public RelDataType resolveColumn(String name, SqlNode ctx) {
> return nameToTypeMap.get(name);
> }
> {code}
> Exception stack:
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 5, column 31:
> Unknown identifier 'c'
> 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:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:834)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:819)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4867)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5693)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:317)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
> at
> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:593)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:237)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:219)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5626)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
> at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:236)
> at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5330)
> at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:940)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateParameterizedExpression(SqlValidatorImpl.java:927)
> at
> org.apache.flink.table.planner.operations.SqlToOperationConverter.lambda$createTableSchema$4(SqlToOperationConverter.java:236)
> at java.util.Optional.ifPresent(Optional.java:159)
> at
> org.apache.flink.table.planner.operations.SqlToOperationConverter.createTableSchema(SqlToOperationConverter.java:232)
> at
> org.apache.flink.table.planner.operations.SqlToOperationConverter.convertCreateTable(SqlToOperationConverter.java:126)
> at
> org.apache.flink.table.planner.operations.SqlToOperationConverter.convert(SqlToOperationConverter.java:98)
> at
> org.apache.flink.table.sqlexec.SqlToOperationConverterTest.testCreateTableWithWatermark(SqlToOperationConverterTest.java:213)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.
[jira] [Commented] (CALCITE-3943) Remove the JSON functions keyword from parser
[ https://issues.apache.org/jira/browse/CALCITE-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088412#comment-17088412 ] Jark Wu commented on CALCITE-3943: -- big +1 for this > Remove the JSON functions keyword from parser > - > > Key: CALCITE-3943 > URL: https://issues.apache.org/jira/browse/CALCITE-3943 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.22.0 >Reporter: Danny Chen >Assignee: Danny Chen >Priority: Major > Fix For: 1.23.0 > > > The JSON functions was introduced in CALCITE-2266, we coded the JSON keywords > into the parser and generates the operator directly, so there is no chance > for downstream projects to change the builtin operator and do some override. > This issue tries to remove these keywords from the parser, we should always > generates SqlUnresolvedFunction instead specific operators in the SQL parser. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-1903) Support charset in LIKE expression
[
https://issues.apache.org/jira/browse/CALCITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127221#comment-16127221
]
Jark Wu commented on CALCITE-1903:
--
Hi [~julianhyde] , if this is not allowed, how to use an unicode literal in SQL
?
> Support charset in LIKE expression
> --
>
> Key: CALCITE-1903
> URL: https://issues.apache.org/jira/browse/CALCITE-1903
> Project: Calcite
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Julian Hyde
>
> From
> http://search-hadoop.com/m/Flink/VkLeQbjp59T6PkF?subj=+How+can+I+set+charset+for+flink+sql+
> The following query
> {code}
> SELECT
> 'HIGH' AS LEVEL,
> 'Firewall uplink bandwidth exception:greater than 1' AS content,
> `system.process.username`,
> `system.process.memory.rss.bytes`
> FROM
> test
> WHERE
> `system.process.username` LIKE '%高危%'
> {code}
> produces the following:
> {code}
> Caused by: org.apache.calcite.runtime.CalciteException: Failed to encode
> '%高危%' in character set 'ISO-8859-1'
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) ~[na:1.8.0_45]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
> Source) ~[na:1.8.0_45]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
> Source) ~[na:1.8.0_45]
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> ~[na:1.8.0_45]
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.util.NlsString.(NlsString.java:81)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:864)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.rex.RexBuilder.makeCharLiteral(RexBuilder.java:1051)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertLiteral(SqlNodeToRexConverterImpl.java:117)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4408)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3787)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.sql.SqlLiteral.accept(SqlLiteral.java:427)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4321)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertExpressionList(StandardConvertletTable.java:968)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertCall(StandardConvertletTable.java:944)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertCall(StandardConvertletTable.java:928)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> ... 50 common frames omitted
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1903) Support charset in LIKE expression
[
https://issues.apache.org/jira/browse/CALCITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16262800#comment-16262800
]
Jark Wu commented on CALCITE-1903:
--
[~yuqi], it is fixed in Flink FLINK-7451
> Support charset in LIKE expression
> --
>
> Key: CALCITE-1903
> URL: https://issues.apache.org/jira/browse/CALCITE-1903
> Project: Calcite
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Julian Hyde
>
> From
> http://search-hadoop.com/m/Flink/VkLeQbjp59T6PkF?subj=+How+can+I+set+charset+for+flink+sql+
> The following query
> {code}
> SELECT
> 'HIGH' AS LEVEL,
> 'Firewall uplink bandwidth exception:greater than 1' AS content,
> `system.process.username`,
> `system.process.memory.rss.bytes`
> FROM
> test
> WHERE
> `system.process.username` LIKE '%高危%'
> {code}
> produces the following:
> {code}
> Caused by: org.apache.calcite.runtime.CalciteException: Failed to encode
> '%高危%' in character set 'ISO-8859-1'
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) ~[na:1.8.0_45]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
> Source) ~[na:1.8.0_45]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
> Source) ~[na:1.8.0_45]
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> ~[na:1.8.0_45]
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.util.NlsString.(NlsString.java:81)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:864)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.rex.RexBuilder.makeCharLiteral(RexBuilder.java:1051)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertLiteral(SqlNodeToRexConverterImpl.java:117)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4408)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3787)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.sql.SqlLiteral.accept(SqlLiteral.java:427)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4321)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertExpressionList(StandardConvertletTable.java:968)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertCall(StandardConvertletTable.java:944)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertCall(StandardConvertletTable.java:928)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> ... 50 common frames omitted
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1903) Support charset in LIKE expression
[
https://issues.apache.org/jira/browse/CALCITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16263680#comment-16263680
]
Jark Wu commented on CALCITE-1903:
--
Yes, non-ascii should be used like {{_UTF16'测试'}}.
> Support charset in LIKE expression
> --
>
> Key: CALCITE-1903
> URL: https://issues.apache.org/jira/browse/CALCITE-1903
> Project: Calcite
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Julian Hyde
>
> From
> http://search-hadoop.com/m/Flink/VkLeQbjp59T6PkF?subj=+How+can+I+set+charset+for+flink+sql+
> The following query
> {code}
> SELECT
> 'HIGH' AS LEVEL,
> 'Firewall uplink bandwidth exception:greater than 1' AS content,
> `system.process.username`,
> `system.process.memory.rss.bytes`
> FROM
> test
> WHERE
> `system.process.username` LIKE '%高危%'
> {code}
> produces the following:
> {code}
> Caused by: org.apache.calcite.runtime.CalciteException: Failed to encode
> '%高危%' in character set 'ISO-8859-1'
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) ~[na:1.8.0_45]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
> Source) ~[na:1.8.0_45]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
> Source) ~[na:1.8.0_45]
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> ~[na:1.8.0_45]
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.util.NlsString.(NlsString.java:81)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:864)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.rex.RexBuilder.makeCharLiteral(RexBuilder.java:1051)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertLiteral(SqlNodeToRexConverterImpl.java:117)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4408)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3787)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at org.apache.calcite.sql.SqlLiteral.accept(SqlLiteral.java:427)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4321)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertExpressionList(StandardConvertletTable.java:968)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertCall(StandardConvertletTable.java:944)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertCall(StandardConvertletTable.java:928)
> ~[flink-table_2.11-1.3.1.jar:1.3.1]
> ... 50 common frames omitted
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-2150) CurrentTimestamp is reduced in subquery
Jark Wu created CALCITE-2150:
Summary: CurrentTimestamp is reduced in subquery
Key: CALCITE-2150
URL: https://issues.apache.org/jira/browse/CALCITE-2150
Project: Calcite
Issue Type: Bug
Reporter: Jark Wu
Assignee: Julian Hyde
I add two unit test with ReduceExpressionsRule.PROJECT_INSTANCE reduce rule in
the commit:
[https://github.com/wuchong/calcite/commit/e76c3ad3cc3ddc5c0bb0c3e385a71296329a7cb5]
The first is "{{select sal, current_timestamp as t from emp" and the
current_timestamp is not reduced as expected.}}
{{But the second query "select sal, sal + 5, t from (select sal,
current_timestamp as t from emp)" the optimized plan is as following:}}
{{// code placeholder}}
{{LogicalProject(SAL=[$0], EXPR$1=[+($0, 5)], T=[2011-07-20 00:00:00])
LogicalProject(SAL=[$5], T=[CURRENT_TIMESTAMP])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])}}{{}}
{{The current_timestamp in the outer Project is reduced as a constant:
2011-07-20 00:00:00 which maybe a bug I think.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2150) CurrentTimestamp is reduced in subquery
[
https://issues.apache.org/jira/browse/CALCITE-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jark Wu updated CALCITE-2150:
-
Description:
I add two unit test with ReduceExpressionsRule.PROJECT_INSTANCE reduce rule in
the commit:
[https://github.com/wuchong/calcite/commit/e76c3ad3cc3ddc5c0bb0c3e385a71296329a7cb5]
The first query is {{"select sal, current_timestamp as t from emp"}} and the
current_timestamp is not reduced as expected.
But the second query {{"select sal, sal + 5, t from (select sal,
current_timestamp as t from emp)"}} the optimized plan is as following:
{code}
LogicalProject(SAL=[$0], EXPR$1=[+($0, 5)], T=[2011-07-20 00:00:00])
LogicalProject(SAL=[$5], T=[CURRENT_TIMESTAMP])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]
{code}
The current_timestamp in the outer Project is reduced as a constant: 2011-07-20
00:00:00 which maybe a bug I think.
was:
I add two unit test with ReduceExpressionsRule.PROJECT_INSTANCE reduce rule in
the commit:
[https://github.com/wuchong/calcite/commit/e76c3ad3cc3ddc5c0bb0c3e385a71296329a7cb5]
The first is "{{select sal, current_timestamp as t from emp" and the
current_timestamp is not reduced as expected.}}
{{But the second query "select sal, sal + 5, t from (select sal,
current_timestamp as t from emp)" the optimized plan is as following:}}
{{// code placeholder}}
{{LogicalProject(SAL=[$0], EXPR$1=[+($0, 5)], T=[2011-07-20 00:00:00])
LogicalProject(SAL=[$5], T=[CURRENT_TIMESTAMP])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])}}{{}}
{{The current_timestamp in the outer Project is reduced as a constant:
2011-07-20 00:00:00 which maybe a bug I think.}}
> CurrentTimestamp is reduced in subquery
> ---
>
> Key: CALCITE-2150
> URL: https://issues.apache.org/jira/browse/CALCITE-2150
> Project: Calcite
> Issue Type: Bug
>Reporter: Jark Wu
>Assignee: Julian Hyde
>Priority: Major
>
> I add two unit test with ReduceExpressionsRule.PROJECT_INSTANCE reduce rule
> in the commit:
> [https://github.com/wuchong/calcite/commit/e76c3ad3cc3ddc5c0bb0c3e385a71296329a7cb5]
> The first query is {{"select sal, current_timestamp as t from emp"}} and the
> current_timestamp is not reduced as expected.
> But the second query {{"select sal, sal + 5, t from (select sal,
> current_timestamp as t from emp)"}} the optimized plan is as following:
>
> {code}
> LogicalProject(SAL=[$0], EXPR$1=[+($0, 5)], T=[2011-07-20 00:00:00])
>LogicalProject(SAL=[$5], T=[CURRENT_TIMESTAMP])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]
> {code}
>
> The current_timestamp in the outer Project is reduced as a constant:
> 2011-07-20 00:00:00 which maybe a bug I think.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[ https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541094#comment-16541094 ] Jark Wu commented on CALCITE-1912: -- Hi [~julianhyde] , I have created a PR for this issue. https://github.com/apache/calcite/pull/759 Could you have a look ? Sorry it took so long. > Support "FOR SYSTEM_TIME AS OF" in regular queries > -- > > Key: CALCITE-1912 > URL: https://issues.apache.org/jira/browse/CALCITE-1912 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde >Priority: Major > > As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" > in Calcite to retrieve table contents as of a given point in time. > [1] > https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[ https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673003#comment-16673003 ] Jark Wu commented on CALCITE-1912: -- Thanks [~julianhyde], I am looking forward to seeing any feedback. > Support "FOR SYSTEM_TIME AS OF" in regular queries > -- > > Key: CALCITE-1912 > URL: https://issues.apache.org/jira/browse/CALCITE-1912 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" > in Calcite to retrieve table contents as of a given point in time. > [1] > https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[ https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674676#comment-16674676 ] Jark Wu commented on CALCITE-1912: -- Thanks. I think the Snapshot operator is a good idea. I will try this and addressed the comments above. > Support "FOR SYSTEM_TIME AS OF" in regular queries > -- > > Key: CALCITE-1912 > URL: https://issues.apache.org/jira/browse/CALCITE-1912 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" > in Calcite to retrieve table contents as of a given point in time. > [1] > https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[ https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686454#comment-16686454 ] Jark Wu commented on CALCITE-1912: -- Hi [~julianhyde] , I have updated the PR and addressed the comments you left above. - Please document SQL syntax in reference.md done - Why the did error message change in lateral.iq? I modified the syntax parse implementation in Parser.jj and passed the lateral.iq test. - Remove the commented-out lines in SqlValidatorImpl done - I think you should rename SqlTemporal to SqlSnapshot. I agree with you. Done. - Add a method RelBuilder.snapshot, and document it in algebra.md done - Rather than TemporalTableScan(table, period) I think you should have Snapshot(TableScan(table), period) done. The current implementation of Snapshot accepts a RelNode input, not restrict to TableScan. I'm not sure whether it is good for now, as we want Snapshot can apply to any relation. Please feel free to leave you thoughts. > Support "FOR SYSTEM_TIME AS OF" in regular queries > -- > > Key: CALCITE-1912 > URL: https://issues.apache.org/jira/browse/CALCITE-1912 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" > in Calcite to retrieve table contents as of a given point in time. > [1] > https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-1295) ReduceExpressionRule should not reduce AS operator
Jark Wu created CALCITE-1295:
Summary: ReduceExpressionRule should not reduce AS operator
Key: CALCITE-1295
URL: https://issues.apache.org/jira/browse/CALCITE-1295
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.8.0
Reporter: Jark Wu
Assignee: Julian Hyde
Priority: Minor
Fix For: 1.8.0, 1.9.0
In extremely rare cases, if we build relation tree ourselves through
RelBuilder.
{code:java}
relBuilder.push(
LogicalProject.create(relBuilder.peek(),
Lists.newArrayList(relBuilder.alias(relBuilder.literal(true), "_c0")),
Lists.newArrayList("_c0")))
{code}
Then we may have AS(true, $1) in the expressions, and AS(true, $1) can
satisfy ReduceExpressionRule, but AS call do not exist in RexImpTable.INSTANCE,
so it throws this :
{code:java}
java.lang.RuntimeException: cannot translate call AS($t0, $t1)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCall(RexToLixTranslator.java:533)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:507)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:219)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:472)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:219)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:214)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:700)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:189)
at
org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:80)
at
org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:59)
at
org.apache.calcite.rex.RexExecutorImpl.reduce(RexExecutorImpl.java:118)
at
org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressionsInternal(ReduceExpressionsRule.java:544)
at
org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressions(ReduceExpressionsRule.java:455)
at
org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressions(ReduceExpressionsRule.java:438)
{{code}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1297) RelBuilder does not translate identity projects even if they rename fields
Jark Wu created CALCITE-1297: Summary: RelBuilder does not translate identity projects even if they rename fields Key: CALCITE-1297 URL: https://issues.apache.org/jira/browse/CALCITE-1297 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.8.0 Reporter: Jark Wu Assignee: Julian Hyde Fix For: 1.8.0, 1.9.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1297) RelBuilder does not translate identity projects even if they rename fields
[
https://issues.apache.org/jira/browse/CALCITE-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335277#comment-15335277
]
Jark Wu commented on CALCITE-1297:
--
Say we have a Table(f0, f1, f2) , and we want to make aliases for every field
using RelBuilder :
{code:java}
relBuilder.project(
Lists.newArrayList(
relBuilder.alias(relBuilder.field("f0"), "a"),
relBuilder.alias(relBuilder.field("f1"), "b"),
relBuilder.alias(relBuilder.field("f2"), "c")),
Lists.newArrayList("a", "b", "c")
);
{code}
But it will not change anything, we do not get the new project.
And I create a PR for fix this : https://github.com/apache/calcite/pull/251
> RelBuilder does not translate identity projects even if they rename fields
> --
>
> Key: CALCITE-1297
> URL: https://issues.apache.org/jira/browse/CALCITE-1297
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Jark Wu
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1297) RelBuilder does not translate identity projects even if they rename fields
[
https://issues.apache.org/jira/browse/CALCITE-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335294#comment-15335294
]
Jark Wu edited comment on CALCITE-1297 at 6/17/16 3:08 AM:
---
However, when I build next expression, such as {{relBuilder.field("a")}}, it
throws
{code}
field [a] not found; input fields are: [f0, f1, f2]
{code}
was (Author: jark):
However, when I build next expression, such as {relBuilder.field("a")}, it
throws
{code}
field [a] not found; input fields are: [f0, f1, f2]
{code}
> RelBuilder does not translate identity projects even if they rename fields
> --
>
> Key: CALCITE-1297
> URL: https://issues.apache.org/jira/browse/CALCITE-1297
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Jark Wu
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1297) RelBuilder does not translate identity projects even if they rename fields
[
https://issues.apache.org/jira/browse/CALCITE-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335294#comment-15335294
]
Jark Wu commented on CALCITE-1297:
--
However, when I build next expression, such as {relBuilder.field("a")}, it
throws
{code}
field [a] not found; input fields are: [f0, f1, f2]
{code}
> RelBuilder does not translate identity projects even if they rename fields
> --
>
> Key: CALCITE-1297
> URL: https://issues.apache.org/jira/browse/CALCITE-1297
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Jark Wu
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1297) RelBuilder does not translate identity projects even if they rename fields
[
https://issues.apache.org/jira/browse/CALCITE-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337616#comment-15337616
]
Jark Wu commented on CALCITE-1297:
--
I'm sorry to disturb you again. I do not get what you mean...
I tried to use RelBuilder.field("a", "a") or RelBuilder.field("a", "f0"), but
it throws {{no relation with alias 'a'; aliases are: [_DataSetTable_0]}}. And I
debug into {{field(String, String)}} and find that the {{stack.peek}} returns a
LogicalTableScan (the stack size is 1), not a Project.
My question is how can I refer to the field using the alias name, after using
an AS ?
I have been confused that why these code exist L788~L799 [1] ? It seems
duplicate with the following codes.
[1]
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/tools/RelBuilder.java#L788-L790
> RelBuilder does not translate identity projects even if they rename fields
> --
>
> Key: CALCITE-1297
> URL: https://issues.apache.org/jira/browse/CALCITE-1297
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Jark Wu
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1309) Support LATERAL TABLE
Jark Wu created CALCITE-1309:
Summary: Support LATERAL TABLE
Key: CALCITE-1309
URL: https://issues.apache.org/jira/browse/CALCITE-1309
Project: Calcite
Issue Type: New Feature
Components: core
Reporter: Jark Wu
Assignee: Julian Hyde
Fix For: 1.9.0
{code}
SELECT MyTable.*, t.s FROM MyTable, LATERAL TABLE(split(MyTable.a)) AS t(s)
{code}
will throw “Encountered "LATERAL TABLE" at line 1, column 38.” exception.
We should support LATERAL TABLE , and allow table function to see earlier
tables in the FROM clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1297) RelBuilder does not translate identity projects even if they rename fields
[ https://issues.apache.org/jira/browse/CALCITE-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367225#comment-15367225 ] Jark Wu commented on CALCITE-1297: -- [~julianhyde], I'm glad to work on it. And I have updated the PR [1] according to my understanding. [1]: https://github.com/apache/calcite/pull/251 > RelBuilder does not translate identity projects even if they rename fields > -- > > Key: CALCITE-1297 > URL: https://issues.apache.org/jira/browse/CALCITE-1297 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.8.0 >Reporter: Jark Wu >Assignee: Julian Hyde > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1356) Release Calcite 1.9.0
[ https://issues.apache.org/jira/browse/CALCITE-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15434400#comment-15434400 ] Jark Wu commented on CALCITE-1356: -- Hi , I hope CALCITE-1309 could be get into 1.9 release. It's required for User-Defined-Table-Function in Apache Flink SQL. > Release Calcite 1.9.0 > - > > Key: CALCITE-1356 > URL: https://issues.apache.org/jira/browse/CALCITE-1356 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Release Apache Calcite version 1.9.0. The plan is "end of August". > Calcite 1.9 will depend on Avatica 1.8 (Avatica release 1.9 will occur later). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1309) Support LATERAL TABLE
[
https://issues.apache.org/jira/browse/CALCITE-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15434440#comment-15434440
]
Jark Wu commented on CALCITE-1309:
--
Hi, Julian, it's a little more complex. After change the parser, the validator
will go into unpredictable error.
> Support LATERAL TABLE
> -
>
> Key: CALCITE-1309
> URL: https://issues.apache.org/jira/browse/CALCITE-1309
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Jark Wu
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
>
> {code}
> SELECT MyTable.*, t.s FROM MyTable, LATERAL TABLE(split(MyTable.a)) AS t(s)
> {code}
> will throw “Encountered "LATERAL TABLE" at line 1, column 38.” exception.
> We should support LATERAL TABLE , and allow table function to see earlier
> tables in the FROM clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1356) Release Calcite 1.9.0
[ https://issues.apache.org/jira/browse/CALCITE-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15435061#comment-15435061 ] Jark Wu commented on CALCITE-1356: -- Ok, I will try to work on it. > Release Calcite 1.9.0 > - > > Key: CALCITE-1356 > URL: https://issues.apache.org/jira/browse/CALCITE-1356 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Release Apache Calcite version 1.9.0. The plan is "end of August". > Calcite 1.9 will depend on Avatica 1.8 (Avatica release 1.9 will occur later). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1461) Hard code in JaninoRelMetadataProvider makes shading for Calcite failed
Jark Wu created CALCITE-1461:
Summary: Hard code in JaninoRelMetadataProvider makes shading for
Calcite failed
Key: CALCITE-1461
URL: https://issues.apache.org/jira/browse/CALCITE-1461
Project: Calcite
Issue Type: Bug
Reporter: Jark Wu
Assignee: Julian Hyde
Fix For: 1.9.0
In {{JaninoRelMetadataProvider.load3}}, the generated class string contains
some hard coded Calcite's classes, such as
{{org.apache.calcite.rel.metadata.MetadataDef}}. After shading Calcite, the
MetadataDef can not be found in the shaded classes. And a compile error will be
thrown.
So it's better to use {{MetadataDef.class.getName()}} to replace the hard code
string.
I'm appreciate to make a PR if you want.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1461) Hard coded class name in JaninoRelMetadataProvider breaks shading
[
https://issues.apache.org/jira/browse/CALCITE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15601168#comment-15601168
]
Jark Wu commented on CALCITE-1461:
--
Here is the PR link: https://github.com/apache/calcite/pull/318
> Hard coded class name in JaninoRelMetadataProvider breaks shading
> -
>
> Key: CALCITE-1461
> URL: https://issues.apache.org/jira/browse/CALCITE-1461
> Project: Calcite
> Issue Type: Bug
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> In {{JaninoRelMetadataProvider.load3}}, the generated class string contains
> some hard coded Calcite's classes, such as
> {{org.apache.calcite.rel.metadata.MetadataDef}}. After shading Calcite, the
> MetadataDef can not be found in the shaded classes. And a compile error will
> be thrown.
> So it's better to use {{MetadataDef.class.getName()}} to replace the hard
> code string.
> I'm appreciate to make a PR if you want.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1472) Support CROSS/OUTER APPLY syntax
Jark Wu created CALCITE-1472: Summary: Support CROSS/OUTER APPLY syntax Key: CALCITE-1472 URL: https://issues.apache.org/jira/browse/CALCITE-1472 Project: Calcite Issue Type: New Feature Reporter: Jark Wu Assignee: Julian Hyde The CROSS/OUTER APPLY is very similar to CROSS JOIN and OUTER JOIN. The difference is that the APPLY operator is used to invoke a table-valued function. This is not a standard SQL syntax , but introduced from MS SQL Server [1]. The APPLY operator can be expressed by Calcite’s LATERAL TABLE . That means the SELECT MyTable.*, t.s FROM MyTable CROSS APPLY split(MyTable.a)) AS t(s) corresponds to : SELECT MyTable.*, t.s FROM MyTable, LATERAL TABLE(split(MyTable.a)) AS t(s) and SELECT MyTable.*, t.s FROM MyTable OUTER APPLY split(MyTable.a)) AS t(s) corresponds to: SELECT MyTable.*, t.s FROM MyTable LEFT JOIN LATERAL TABLE(split(MyTable.a)) AS t(s) ON TRUE The ON TRUE part is necessary for LEFT JOIN, but it's trivial for users. That's why I'm introducing "CROSS/OUTER APPLY" which will simplify the SQL a lot. As the APPLY can be expressed by LATERAL, so the only thing we need to touch is the Parser (see [2] and search FLINK to find the modification). [1] https://technet.microsoft.com/en-us/library/ms175156(v=sql.105).aspx [2] https://github.com/wuchong/flink/blob/60812e51156ec9fa6088154d2f6dea8c1ff9ac17/flink-libraries/flink-table/src/main/codegen/templates/Parser.jj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1472) Support CROSS/OUTER APPLY syntax
[ https://issues.apache.org/jira/browse/CALCITE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15611128#comment-15611128 ] Jark Wu commented on CALCITE-1472: -- Yes, you are right. APPLY should be a non-reserved keyword. > Support CROSS/OUTER APPLY syntax > > > Key: CALCITE-1472 > URL: https://issues.apache.org/jira/browse/CALCITE-1472 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde > > The CROSS/OUTER APPLY is very similar to CROSS JOIN and OUTER JOIN. The > difference is that the APPLY operator is used to invoke a table-valued > function. This is not a standard SQL syntax , but introduced from MS SQL > Server [1]. > The APPLY operator can be expressed by Calcite’s LATERAL TABLE . That means > the > SELECT MyTable.*, t.s FROM MyTable CROSS APPLY split(MyTable.a)) AS t(s) > corresponds to : > SELECT MyTable.*, t.s FROM MyTable, LATERAL TABLE(split(MyTable.a)) AS t(s) > and > SELECT MyTable.*, t.s FROM MyTable OUTER APPLY split(MyTable.a)) AS t(s) > corresponds to: > SELECT MyTable.*, t.s FROM MyTable LEFT JOIN LATERAL TABLE(split(MyTable.a)) > AS t(s) ON TRUE > The ON TRUE part is necessary for LEFT JOIN, but it's trivial for users. > That's why I'm introducing "CROSS/OUTER APPLY" which will simplify the SQL a > lot. > As the APPLY can be expressed by LATERAL, so the only thing we need to touch > is the Parser (see [2] and search FLINK to find the modification). > [1] https://technet.microsoft.com/en-us/library/ms175156(v=sql.105).aspx > [2] > https://github.com/wuchong/flink/blob/60812e51156ec9fa6088154d2f6dea8c1ff9ac17/flink-libraries/flink-table/src/main/codegen/templates/Parser.jj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1472) Support CROSS/OUTER APPLY syntax
[ https://issues.apache.org/jira/browse/CALCITE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614072#comment-15614072 ] Jark Wu commented on CALCITE-1472: -- I'm not sure I understand correctly. Could you explain more about How it could be enabled by a SqlConformance setting ? > Support CROSS/OUTER APPLY syntax > > > Key: CALCITE-1472 > URL: https://issues.apache.org/jira/browse/CALCITE-1472 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde > > The CROSS/OUTER APPLY is very similar to CROSS JOIN and OUTER JOIN. The > difference is that the APPLY operator is used to invoke a table-valued > function. This is not a standard SQL syntax , but introduced from MS SQL > Server [1]. > The APPLY operator can be expressed by Calcite’s LATERAL TABLE . That means > the > SELECT MyTable.*, t.s FROM MyTable CROSS APPLY split(MyTable.a)) AS t(s) > corresponds to : > SELECT MyTable.*, t.s FROM MyTable, LATERAL TABLE(split(MyTable.a)) AS t(s) > and > SELECT MyTable.*, t.s FROM MyTable OUTER APPLY split(MyTable.a)) AS t(s) > corresponds to: > SELECT MyTable.*, t.s FROM MyTable LEFT JOIN LATERAL TABLE(split(MyTable.a)) > AS t(s) ON TRUE > The ON TRUE part is necessary for LEFT JOIN, but it's trivial for users. > That's why I'm introducing "CROSS/OUTER APPLY" which will simplify the SQL a > lot. > As the APPLY can be expressed by LATERAL, so the only thing we need to touch > is the Parser (see [2] and search FLINK to find the modification). > [1] https://technet.microsoft.com/en-us/library/ms175156(v=sql.105).aspx > [2] > https://github.com/wuchong/flink/blob/60812e51156ec9fa6088154d2f6dea8c1ff9ac17/flink-libraries/flink-table/src/main/codegen/templates/Parser.jj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1472) Support CROSS/OUTER APPLY syntax
[ https://issues.apache.org/jira/browse/CALCITE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614178#comment-15614178 ] Jark Wu commented on CALCITE-1472: -- Thank you for the detailed explanation. > Support CROSS/OUTER APPLY syntax > > > Key: CALCITE-1472 > URL: https://issues.apache.org/jira/browse/CALCITE-1472 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde > > The CROSS/OUTER APPLY is very similar to CROSS JOIN and OUTER JOIN. The > difference is that the APPLY operator is used to invoke a table-valued > function. This is not a standard SQL syntax , but introduced from MS SQL > Server [1]. > The APPLY operator can be expressed by Calcite’s LATERAL TABLE . That means > the > SELECT MyTable.*, t.s FROM MyTable CROSS APPLY split(MyTable.a)) AS t(s) > corresponds to : > SELECT MyTable.*, t.s FROM MyTable, LATERAL TABLE(split(MyTable.a)) AS t(s) > and > SELECT MyTable.*, t.s FROM MyTable OUTER APPLY split(MyTable.a)) AS t(s) > corresponds to: > SELECT MyTable.*, t.s FROM MyTable LEFT JOIN LATERAL TABLE(split(MyTable.a)) > AS t(s) ON TRUE > The ON TRUE part is necessary for LEFT JOIN, but it's trivial for users. > That's why I'm introducing "CROSS/OUTER APPLY" which will simplify the SQL a > lot. > As the APPLY can be expressed by LATERAL, so the only thing we need to touch > is the Parser (see [2] and search FLINK to find the modification). > [1] https://technet.microsoft.com/en-us/library/ms175156(v=sql.105).aspx > [2] > https://github.com/wuchong/flink/blob/60812e51156ec9fa6088154d2f6dea8c1ff9ac17/flink-libraries/flink-table/src/main/codegen/templates/Parser.jj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1472) Support CROSS/OUTER APPLY syntax
[ https://issues.apache.org/jira/browse/CALCITE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15661186#comment-15661186 ] Jark Wu commented on CALCITE-1472: -- Hi [~julianhyde], sorry for the late response. Could we support MS SQL SERVER's syntax first ? Because SQL SERVER's syntax is simpler and only support table function which will be easy to implement I think. > Support CROSS/OUTER APPLY syntax > > > Key: CALCITE-1472 > URL: https://issues.apache.org/jira/browse/CALCITE-1472 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde > > The CROSS/OUTER APPLY is very similar to CROSS JOIN and OUTER JOIN. The > difference is that the APPLY operator is used to invoke a table-valued > function. This is not a standard SQL syntax , but introduced from MS SQL > Server [1]. > The APPLY operator can be expressed by Calcite’s LATERAL TABLE . That means > the > SELECT MyTable.*, t.s FROM MyTable CROSS APPLY split(MyTable.a)) AS t(s) > corresponds to : > SELECT MyTable.*, t.s FROM MyTable, LATERAL TABLE(split(MyTable.a)) AS t(s) > and > SELECT MyTable.*, t.s FROM MyTable OUTER APPLY split(MyTable.a)) AS t(s) > corresponds to: > SELECT MyTable.*, t.s FROM MyTable LEFT JOIN LATERAL TABLE(split(MyTable.a)) > AS t(s) ON TRUE > The ON TRUE part is necessary for LEFT JOIN, but it's trivial for users. > That's why I'm introducing "CROSS/OUTER APPLY" which will simplify the SQL a > lot. > As the APPLY can be expressed by LATERAL, so the only thing we need to touch > is the Parser (see [2] and search FLINK to find the modification). > [1] https://technet.microsoft.com/en-us/library/ms175156(v=sql.105).aspx > [2] > https://github.com/wuchong/flink/blob/60812e51156ec9fa6088154d2f6dea8c1ff9ac17/flink-libraries/flink-table/src/main/codegen/templates/Parser.jj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1472) Support CROSS/OUTER APPLY syntax
[
https://issues.apache.org/jira/browse/CALCITE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15662597#comment-15662597
]
Jark Wu commented on CALCITE-1472:
--
Yes, you are right, see [this
link|https://msdn.microsoft.com/en-us/library/bb386954(v=vs.110).aspx].
It seems that it conflicts with the current `LATERAL TABLE`. So we have to
support the syntax of {{SELECT * FROM EMP(1, 2)}} for SQL Server's
SqlConformance, right ?
> Support CROSS/OUTER APPLY syntax
>
>
> Key: CALCITE-1472
> URL: https://issues.apache.org/jira/browse/CALCITE-1472
> Project: Calcite
> Issue Type: New Feature
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> The CROSS/OUTER APPLY is very similar to CROSS JOIN and OUTER JOIN. The
> difference is that the APPLY operator is used to invoke a table-valued
> function. This is not a standard SQL syntax , but introduced from MS SQL
> Server [1].
> The APPLY operator can be expressed by Calcite’s LATERAL TABLE . That means
> the
> SELECT MyTable.*, t.s FROM MyTable CROSS APPLY split(MyTable.a)) AS t(s)
> corresponds to :
> SELECT MyTable.*, t.s FROM MyTable, LATERAL TABLE(split(MyTable.a)) AS t(s)
> and
> SELECT MyTable.*, t.s FROM MyTable OUTER APPLY split(MyTable.a)) AS t(s)
> corresponds to:
> SELECT MyTable.*, t.s FROM MyTable LEFT JOIN LATERAL TABLE(split(MyTable.a))
> AS t(s) ON TRUE
> The ON TRUE part is necessary for LEFT JOIN, but it's trivial for users.
> That's why I'm introducing "CROSS/OUTER APPLY" which will simplify the SQL a
> lot.
> As the APPLY can be expressed by LATERAL, so the only thing we need to touch
> is the Parser (see [2] and search FLINK to find the modification).
> [1] https://technet.microsoft.com/en-us/library/ms175156(v=sql.105).aspx
> [2]
> https://github.com/wuchong/flink/blob/60812e51156ec9fa6088154d2f6dea8c1ff9ac17/flink-libraries/flink-table/src/main/codegen/templates/Parser.jj
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1472) Support CROSS/OUTER APPLY syntax
[ https://issues.apache.org/jira/browse/CALCITE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15704538#comment-15704538 ] Jark Wu commented on CALCITE-1472: -- Hi [~julianhyde] , I think the change is very good. > Support CROSS/OUTER APPLY syntax > > > Key: CALCITE-1472 > URL: https://issues.apache.org/jira/browse/CALCITE-1472 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde > > The CROSS/OUTER APPLY is very similar to CROSS JOIN and OUTER JOIN. The > difference is that the APPLY operator is used to invoke a table-valued > function. This is not a standard SQL syntax , but introduced from MS SQL > Server [1]. > The APPLY operator can be expressed by Calcite’s LATERAL TABLE . That means > the > SELECT MyTable.*, t.s FROM MyTable CROSS APPLY split(MyTable.a)) AS t(s) > corresponds to : > SELECT MyTable.*, t.s FROM MyTable, LATERAL TABLE(split(MyTable.a)) AS t(s) > and > SELECT MyTable.*, t.s FROM MyTable OUTER APPLY split(MyTable.a)) AS t(s) > corresponds to: > SELECT MyTable.*, t.s FROM MyTable LEFT JOIN LATERAL TABLE(split(MyTable.a)) > AS t(s) ON TRUE > The ON TRUE part is necessary for LEFT JOIN, but it's trivial for users. > That's why I'm introducing "CROSS/OUTER APPLY" which will simplify the SQL a > lot. > As the APPLY can be expressed by LATERAL, so the only thing we need to touch > is the Parser (see [2] and search FLINK to find the modification). > [1] https://technet.microsoft.com/en-us/library/ms175156(v=sql.105).aspx > [2] > https://github.com/wuchong/flink/blob/60812e51156ec9fa6088154d2f6dea8c1ff9ac17/flink-libraries/flink-table/src/main/codegen/templates/Parser.jj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
Jark Wu created CALCITE-1912: Summary: Support "FOR SYSTEM_TIME AS OF" in regular queries Key: CALCITE-1912 URL: https://issues.apache.org/jira/browse/CALCITE-1912 Project: Calcite Issue Type: New Feature Reporter: Jark Wu Assignee: Julian Hyde As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" in Calcite to retrieve table contents as of a given point in time. [1] https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1917) Support column reference in "FOR SYSTEM_TIME AS OF"
Jark Wu created CALCITE-1917:
Summary: Support column reference in "FOR SYSTEM_TIME AS OF"
Key: CALCITE-1917
URL: https://issues.apache.org/jira/browse/CALCITE-1917
Project: Calcite
Issue Type: New Feature
Reporter: Jark Wu
Assignee: Julian Hyde
you mean it can be covered by standard. I agree, the query I posted in the
previous mail can be rewrote as a subquery:
As discussed in mailing list[1], the standard says QSTPS can’t contain a column
reference. So when joining the Orders to the Products table for the price as of
the time the order was placed is impossible using "FOR SYSTEM_TIME AS OF". But
can be expressed using a subquery, such as:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime AND
sysEnd > O.orderTime) AS P
ON o.productId = p.productId
{code}
But subquery is too complex for users. We know that the standard says it can’t
contain a column reference. We initialize this discuss as we would like to
"extend" the standard to simplify such query.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1917) Support column reference in "FOR SYSTEM_TIME AS OF"
[
https://issues.apache.org/jira/browse/CALCITE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jark Wu updated CALCITE-1917:
-
Description:
As discussed in mailing list[1], the standard says QSTPS can’t contain a column
reference. So when joining the Orders to the Products table for the price as of
the time the order was placed is impossible using "FOR SYSTEM_TIME AS OF". But
can be expressed using a subquery, such as:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime AND
sysEnd > O.orderTime) AS P
ON o.productId = p.productId
{code}
But subquery is too complex for users. We know that the standard says it can’t
contain a column reference. We initialize this discuss as we would like to
"extend" the standard to simplify such query.
[1]
https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
was:
you mean it can be covered by standard. I agree, the query I posted in the
previous mail can be rewrote as a subquery:
As discussed in mailing list[1], the standard says QSTPS can’t contain a column
reference. So when joining the Orders to the Products table for the price as of
the time the order was placed is impossible using "FOR SYSTEM_TIME AS OF". But
can be expressed using a subquery, such as:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime AND
sysEnd > O.orderTime) AS P
ON o.productId = p.productId
{code}
But subquery is too complex for users. We know that the standard says it can’t
contain a column reference. We initialize this discuss as we would like to
"extend" the standard to simplify such query.
> Support column reference in "FOR SYSTEM_TIME AS OF"
> ---
>
> Key: CALCITE-1917
> URL: https://issues.apache.org/jira/browse/CALCITE-1917
> Project: Calcite
> Issue Type: New Feature
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> As discussed in mailing list[1], the standard says QSTPS can’t contain a
> column reference. So when joining the Orders to the Products table for the
> price as of the time the order was placed is impossible using "FOR
> SYSTEM_TIME AS OF". But can be expressed using a subquery, such as:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime
> AND sysEnd > O.orderTime) AS P
> ON o.productId = p.productId
> {code}
> But subquery is too complex for users. We know that the standard says it
> can’t contain a column reference. We initialize this discuss as we would like
> to "extend" the standard to simplify such query.
> [1]
> https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1917) Support column reference in "FOR SYSTEM_TIME AS OF"
[
https://issues.apache.org/jira/browse/CALCITE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jark Wu updated CALCITE-1917:
-
Description:
As discussed in mailing list[1], the standard says QSTPS can’t contain a column
reference. So when joining the Orders to the Products table for the price as of
the time the order was placed is impossible using "FOR SYSTEM_TIME AS OF". But
can be expressed using a subquery, such as:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime AND
sysEnd > O.orderTime) AS P
ON o.productId = p.productId
{code}
But subquery is too complex for users. We know that the standard says it can’t
contain a column reference. We initialize this discuss as we would like to
"extend" the standard to simplify such query:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL ProductPrices FOR SYSTEM_TIME AS OF O.orderTime AS P
ON o.productId = p.productId
{code}
[1]
https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
was:
As discussed in mailing list[1], the standard says QSTPS can’t contain a column
reference. So when joining the Orders to the Products table for the price as of
the time the order was placed is impossible using "FOR SYSTEM_TIME AS OF". But
can be expressed using a subquery, such as:
{code}
SELECT *
FROM Orders AS o
JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime AND
sysEnd > O.orderTime) AS P
ON o.productId = p.productId
{code}
But subquery is too complex for users. We know that the standard says it can’t
contain a column reference. We initialize this discuss as we would like to
"extend" the standard to simplify such query.
[1]
https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
> Support column reference in "FOR SYSTEM_TIME AS OF"
> ---
>
> Key: CALCITE-1917
> URL: https://issues.apache.org/jira/browse/CALCITE-1917
> Project: Calcite
> Issue Type: New Feature
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> As discussed in mailing list[1], the standard says QSTPS can’t contain a
> column reference. So when joining the Orders to the Products table for the
> price as of the time the order was placed is impossible using "FOR
> SYSTEM_TIME AS OF". But can be expressed using a subquery, such as:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime
> AND sysEnd > O.orderTime) AS P
> ON o.productId = p.productId
> {code}
> But subquery is too complex for users. We know that the standard says it
> can’t contain a column reference. We initialize this discuss as we would like
> to "extend" the standard to simplify such query:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL ProductPrices FOR SYSTEM_TIME AS OF O.orderTime AS P
> ON o.productId = p.productId
> {code}
> [1]
> https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1917) Support column reference in "FOR SYSTEM_TIME AS OF"
[
https://issues.apache.org/jira/browse/CALCITE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110168#comment-16110168
]
Jark Wu commented on CALCITE-1917:
--
Hi [~julianhyde] , I expect that we can continue the discussion about joining
temporal tables (i.e. whether to support column reference) under this JIRA :)
> Support column reference in "FOR SYSTEM_TIME AS OF"
> ---
>
> Key: CALCITE-1917
> URL: https://issues.apache.org/jira/browse/CALCITE-1917
> Project: Calcite
> Issue Type: New Feature
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> As discussed in mailing list[1], the standard says QSTPS can’t contain a
> column reference. So when joining the Orders to the Products table for the
> price as of the time the order was placed is impossible using "FOR
> SYSTEM_TIME AS OF". But can be expressed using a subquery, such as:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime
> AND sysEnd > O.orderTime) AS P
> ON o.productId = p.productId
> {code}
> But subquery is too complex for users. We know that the standard says it
> can’t contain a column reference. We initialize this discuss as we would like
> to "extend" the standard to simplify such query:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL ProductPrices FOR SYSTEM_TIME AS OF O.orderTime AS P
> ON o.productId = p.productId
> {code}
> [1]
> https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1912) Support "FOR SYSTEM_TIME AS OF" in regular queries
[ https://issues.apache.org/jira/browse/CALCITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113902#comment-16113902 ] Jark Wu commented on CALCITE-1912: -- Hi [~julianhyde] do you have suggestions/reference about how to implement this ? Especially, the "temporal table in one of the standard data sets". Do we need to introduce a new interface `TemporalTable` which extends `org.apache.calcite.schema.impl.Table` ? > Support "FOR SYSTEM_TIME AS OF" in regular queries > -- > > Key: CALCITE-1912 > URL: https://issues.apache.org/jira/browse/CALCITE-1912 > Project: Calcite > Issue Type: New Feature >Reporter: Jark Wu >Assignee: Julian Hyde > > As discussed in mailling list[1], we hope to support "FOR SYSTEM_TIME AS OF" > in Calcite to retrieve table contents as of a given point in time. > [1] > https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1917) Support column reference in "FOR SYSTEM_TIME AS OF"
[
https://issues.apache.org/jira/browse/CALCITE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113904#comment-16113904
]
Jark Wu commented on CALCITE-1917:
--
I'm glad to see you agree with it. I will work for the first version in the
next days.
> Support column reference in "FOR SYSTEM_TIME AS OF"
> ---
>
> Key: CALCITE-1917
> URL: https://issues.apache.org/jira/browse/CALCITE-1917
> Project: Calcite
> Issue Type: New Feature
>Reporter: Jark Wu
>Assignee: Julian Hyde
>
> As discussed in mailing list[1], the standard says QSTPS can’t contain a
> column reference. So when joining the Orders to the Products table for the
> price as of the time the order was placed is impossible using "FOR
> SYSTEM_TIME AS OF". But can be expressed using a subquery, such as:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL (SELECT * FROM ProductPrices WHERE sysStart <= O.orderTime
> AND sysEnd > O.orderTime) AS P
> ON o.productId = p.productId
> {code}
> But subquery is too complex for users. We know that the standard says it
> can’t contain a column reference. We initialize this discuss as we would like
> to "extend" the standard to simplify such query:
> {code}
> SELECT *
> FROM Orders AS o
> JOIN LATERAL ProductPrices FOR SYSTEM_TIME AS OF O.orderTime AS P
> ON o.productId = p.productId
> {code}
> [1]
> https://lists.apache.org/thread.html/f877f356a8365bf74ea7d8e4a171224104d653cf73861afb2901a58f@%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
