[jira] [Comment Edited] (CALCITE-6060) The named parameter OFFSET in window functions should not conflicts with reserved keywords
[
https://issues.apache.org/jira/browse/CALCITE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778579#comment-17778579
]
lincoln lee edited comment on CALCITE-6060 at 10/23/23 8:54 AM:
The following content is from the discussion in the pull request, pasted here
for easy tracking
!screenshot-1.png!
was (Author: lincoln.86xy):
The following content is from the discussion in the pull request, paste here
for easy tracking
!screenshot-1.png!
> The named parameter OFFSET in window functions should not conflicts with
> reserved keywords
> --
>
> Key: CALCITE-6060
> URL: https://issues.apache.org/jira/browse/CALCITE-6060
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.26.0, 1.35.0
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png
>
>
> CALCITE-4171 adds support for named params in window function, but the new
> param name OFFSET conflicts with the reserved keyword, so it can't be used
> directly, users must use it with double quotes(`OFFSET`),
> which is inconvenient (especially for the built-in window functions, which I
> think shouldn't occur, actually I tend to think this is a 'bug').
> For example, a case like this:
> {code}
> @Test void testTableFunctionTumbleWithParamNames() {
> final String sql = "select *\n"
> + "from table(\n"
> + "tumble(\n"
> + " DATA => table Shipments,\n"
> + " TIMECOL => descriptor(rowtime),\n"
> + " SIZE => INTERVAL '1' MINUTE,\n"
> + " OFFSET => INTERVAL '-1' MINUTE))";
> sql(sql).ok();
> }
> {code}
> will cause SqlParseException:
> {code}
> org.apache.calcite.sql.parser.SqlParseException: Incorrect syntax near the
> keyword 'OFFSET' at line 8, column 3.
> Was expecting one of:
> "ABS" ...
> "ARRAY" ...
> "AVG" ...
> ...
> {code}
> Only `OFFSET` works.
> If we agree to rename it, I suggest replacing it with OFFSETSIZE, with the
> following considerations:
> 1. similar to window size name SIZE, the current name actually omits SIZE, so
> calling it OFFSETSIZE would be easier for users to understand
> 2. be consistent with TIMECOL without underscores
> 3. btw, we found that Azure Streaming Analytics [1] also uses the name
> OFFSETSIZE
> 1.
> https://learn.microsoft.com/en-us/stream-analytics-query/hopping-window-azure-stream-analytics#arguments
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CALCITE-6060) The named parameter OFFSET in window functions should not conflicts with reserved keywords
[
https://issues.apache.org/jira/browse/CALCITE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
lincoln lee closed CALCITE-6060.
Resolution: Won't Fix
> The named parameter OFFSET in window functions should not conflicts with
> reserved keywords
> --
>
> Key: CALCITE-6060
> URL: https://issues.apache.org/jira/browse/CALCITE-6060
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.26.0, 1.35.0
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png
>
>
> CALCITE-4171 adds support for named params in window function, but the new
> param name OFFSET conflicts with the reserved keyword, so it can't be used
> directly, users must use it with double quotes(`OFFSET`),
> which is inconvenient (especially for the built-in window functions, which I
> think shouldn't occur, actually I tend to think this is a 'bug').
> For example, a case like this:
> {code}
> @Test void testTableFunctionTumbleWithParamNames() {
> final String sql = "select *\n"
> + "from table(\n"
> + "tumble(\n"
> + " DATA => table Shipments,\n"
> + " TIMECOL => descriptor(rowtime),\n"
> + " SIZE => INTERVAL '1' MINUTE,\n"
> + " OFFSET => INTERVAL '-1' MINUTE))";
> sql(sql).ok();
> }
> {code}
> will cause SqlParseException:
> {code}
> org.apache.calcite.sql.parser.SqlParseException: Incorrect syntax near the
> keyword 'OFFSET' at line 8, column 3.
> Was expecting one of:
> "ABS" ...
> "ARRAY" ...
> "AVG" ...
> ...
> {code}
> Only `OFFSET` works.
> If we agree to rename it, I suggest replacing it with OFFSETSIZE, with the
> following considerations:
> 1. similar to window size name SIZE, the current name actually omits SIZE, so
> calling it OFFSETSIZE would be easier for users to understand
> 2. be consistent with TIMECOL without underscores
> 3. btw, we found that Azure Streaming Analytics [1] also uses the name
> OFFSETSIZE
> 1.
> https://learn.microsoft.com/en-us/stream-analytics-query/hopping-window-azure-stream-analytics#arguments
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6060) The named parameter OFFSET in window functions should not conflicts with reserved keywords
[
https://issues.apache.org/jira/browse/CALCITE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778579#comment-17778579
]
lincoln lee commented on CALCITE-6060:
--
The following content is from the discussion in the pull request, paste here
for easy tracking
!screenshot-1.png!
> The named parameter OFFSET in window functions should not conflicts with
> reserved keywords
> --
>
> Key: CALCITE-6060
> URL: https://issues.apache.org/jira/browse/CALCITE-6060
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.26.0, 1.35.0
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png
>
>
> CALCITE-4171 adds support for named params in window function, but the new
> param name OFFSET conflicts with the reserved keyword, so it can't be used
> directly, users must use it with double quotes(`OFFSET`),
> which is inconvenient (especially for the built-in window functions, which I
> think shouldn't occur, actually I tend to think this is a 'bug').
> For example, a case like this:
> {code}
> @Test void testTableFunctionTumbleWithParamNames() {
> final String sql = "select *\n"
> + "from table(\n"
> + "tumble(\n"
> + " DATA => table Shipments,\n"
> + " TIMECOL => descriptor(rowtime),\n"
> + " SIZE => INTERVAL '1' MINUTE,\n"
> + " OFFSET => INTERVAL '-1' MINUTE))";
> sql(sql).ok();
> }
> {code}
> will cause SqlParseException:
> {code}
> org.apache.calcite.sql.parser.SqlParseException: Incorrect syntax near the
> keyword 'OFFSET' at line 8, column 3.
> Was expecting one of:
> "ABS" ...
> "ARRAY" ...
> "AVG" ...
> ...
> {code}
> Only `OFFSET` works.
> If we agree to rename it, I suggest replacing it with OFFSETSIZE, with the
> following considerations:
> 1. similar to window size name SIZE, the current name actually omits SIZE, so
> calling it OFFSETSIZE would be easier for users to understand
> 2. be consistent with TIMECOL without underscores
> 3. btw, we found that Azure Streaming Analytics [1] also uses the name
> OFFSETSIZE
> 1.
> https://learn.microsoft.com/en-us/stream-analytics-query/hopping-window-azure-stream-analytics#arguments
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6060) The named parameter OFFSET in window functions should not conflicts with reserved keywords
[
https://issues.apache.org/jira/browse/CALCITE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
lincoln lee updated CALCITE-6060:
-
Attachment: screenshot-1.png
> The named parameter OFFSET in window functions should not conflicts with
> reserved keywords
> --
>
> Key: CALCITE-6060
> URL: https://issues.apache.org/jira/browse/CALCITE-6060
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.26.0, 1.35.0
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png
>
>
> CALCITE-4171 adds support for named params in window function, but the new
> param name OFFSET conflicts with the reserved keyword, so it can't be used
> directly, users must use it with double quotes(`OFFSET`),
> which is inconvenient (especially for the built-in window functions, which I
> think shouldn't occur, actually I tend to think this is a 'bug').
> For example, a case like this:
> {code}
> @Test void testTableFunctionTumbleWithParamNames() {
> final String sql = "select *\n"
> + "from table(\n"
> + "tumble(\n"
> + " DATA => table Shipments,\n"
> + " TIMECOL => descriptor(rowtime),\n"
> + " SIZE => INTERVAL '1' MINUTE,\n"
> + " OFFSET => INTERVAL '-1' MINUTE))";
> sql(sql).ok();
> }
> {code}
> will cause SqlParseException:
> {code}
> org.apache.calcite.sql.parser.SqlParseException: Incorrect syntax near the
> keyword 'OFFSET' at line 8, column 3.
> Was expecting one of:
> "ABS" ...
> "ARRAY" ...
> "AVG" ...
> ...
> {code}
> Only `OFFSET` works.
> If we agree to rename it, I suggest replacing it with OFFSETSIZE, with the
> following considerations:
> 1. similar to window size name SIZE, the current name actually omits SIZE, so
> calling it OFFSETSIZE would be easier for users to understand
> 2. be consistent with TIMECOL without underscores
> 3. btw, we found that Azure Streaming Analytics [1] also uses the name
> OFFSETSIZE
> 1.
> https://learn.microsoft.com/en-us/stream-analytics-query/hopping-window-azure-stream-analytics#arguments
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6060) The named parameter OFFSET in window functions should not conflicts with reserved keywords
lincoln lee created CALCITE-6060:
Summary: The named parameter OFFSET in window functions should not
conflicts with reserved keywords
Key: CALCITE-6060
URL: https://issues.apache.org/jira/browse/CALCITE-6060
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.35.0, 1.26.0
Reporter: lincoln lee
CALCITE-4171 adds support for named params in window function, but the new
param name OFFSET conflicts with the reserved keyword, so it can't be used
directly, users must use it with double quotes(`OFFSET`),
which is inconvenient (especially for the built-in window functions, which I
think shouldn't occur, actually I tend to think this is a 'bug').
For example, a case like this:
{code}
@Test void testTableFunctionTumbleWithParamNames() {
final String sql = "select *\n"
+ "from table(\n"
+ "tumble(\n"
+ " DATA => table Shipments,\n"
+ " TIMECOL => descriptor(rowtime),\n"
+ " SIZE => INTERVAL '1' MINUTE,\n"
+ " OFFSET => INTERVAL '-1' MINUTE))";
sql(sql).ok();
}
{code}
will cause SqlParseException:
{code}
org.apache.calcite.sql.parser.SqlParseException: Incorrect syntax near the
keyword 'OFFSET' at line 8, column 3.
Was expecting one of:
"ABS" ...
"ARRAY" ...
"AVG" ...
...
{code}
Only `OFFSET` works.
If we agree to rename it, I suggest replacing it with OFFSETSIZE, with the
following considerations:
1. similar to window size name SIZE, the current name actually omits SIZE, so
calling it OFFSETSIZE would be easier for users to understand
2. be consistent with TIMECOL without underscores
3. btw, we found that Azure Streaming Analytics [1] also uses the name
OFFSETSIZE
1.
https://learn.microsoft.com/en-us/stream-analytics-query/hopping-window-azure-stream-analytics#arguments
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597657#comment-17597657
]
lincoln lee commented on CALCITE-5251:
--
[~rubenql] and [~julianhyde] thanks for reminding! I added the description of
related scenario for this ticket, welcome more comments for this change.
BTW, I totally agree with your discussion about the current hints 'fragile'
problem (in CALCITE-5177), but I don't have a good idea for lacking of a deep
understanding of the previous implementation and design details.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 1. Current `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table(As query hints, all operators
> included in the query may have the need to propagate hint, current hint
> propagation depends on whether the node is hintable).
> 2. When do a [temporal join in
> Flink|https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/sql/queries/joins/#event-time-temporal-join],
> the snapshot maybe optimized in some cases (to reserve less versions of the
> managed versioned-table), e.g.,
> {code}
> select /*+ snapshot('max-version'='1') */ stream *
> from orders o join products_temporal for system_time as of orders.proctime as
> p
> on o.productid = p.productid
> {code}
> currently, the following node tree has no hint on `LogicalSnapshot`
> {code}
> LogicalDelta
> LogicalProject(PROCTIME=[$0], PRODUCTID=[$1], ORDERID=[$2],
> PRODUCTID0=[$3], NAME=[$4], SUPPLIERID=[$5], SYS_START=[$6], SYS_END=[$7])
> LogicalFilter(condition=[=($1, $3)])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[\{0}])
> LogicalTableScan(table=[[CATALOG, SALES, ORDERS]])
> LogicalSnapshot(period=[$cor0.PROCTIME])
> LogicalTableScan(table=[[CATALOG, SALES, PRODUCTS_TEMPORAL]])
> {code}
> If snapshot could be extended to support hint, it would make this
> optimization possible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
lincoln lee updated CALCITE-5251:
-
Description:
1. Current `snapshot` does not support hint yet and this blocks hint
propagation to the underlying temporal table(As query hints, all operators
included in the query may have the need to propagate hint, current hint
propagation depends on whether the node is hintable).
2. When do a [temporal join in
Flink|https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/sql/queries/joins/#event-time-temporal-join],
the snapshot maybe optimized in some cases (to reserve less versions of the
managed versioned-table), e.g.,
{code}
select /*+ snapshot('max-version'='1') */ stream *
from orders o join products_temporal for system_time as of orders.proctime as p
on o.productid = p.productid
{code}
currently, the following node tree has no hint on `LogicalSnapshot`
{code}
LogicalDelta
LogicalProject(PROCTIME=[$0], PRODUCTID=[$1], ORDERID=[$2], PRODUCTID0=[$3],
NAME=[$4], SUPPLIERID=[$5], SYS_START=[$6], SYS_END=[$7])
LogicalFilter(condition=[=($1, $3)])
LogicalCorrelate(correlation=[$cor0], joinType=[inner],
requiredColumns=[\{0}])
LogicalTableScan(table=[[CATALOG, SALES, ORDERS]])
LogicalSnapshot(period=[$cor0.PROCTIME])
LogicalTableScan(table=[[CATALOG, SALES, PRODUCTS_TEMPORAL]])
{code}
If snapshot could be extended to support hint, it would make this optimization
possible.
was:Current, `snapshot` does not support hint yet and this blocks hint
propagation to the underlying temporal table.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 1. Current `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table(As query hints, all operators
> included in the query may have the need to propagate hint, current hint
> propagation depends on whether the node is hintable).
> 2. When do a [temporal join in
> Flink|https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/sql/queries/joins/#event-time-temporal-join],
> the snapshot maybe optimized in some cases (to reserve less versions of the
> managed versioned-table), e.g.,
> {code}
> select /*+ snapshot('max-version'='1') */ stream *
> from orders o join products_temporal for system_time as of orders.proctime as
> p
> on o.productid = p.productid
> {code}
> currently, the following node tree has no hint on `LogicalSnapshot`
> {code}
> LogicalDelta
> LogicalProject(PROCTIME=[$0], PRODUCTID=[$1], ORDERID=[$2],
> PRODUCTID0=[$3], NAME=[$4], SUPPLIERID=[$5], SYS_START=[$6], SYS_END=[$7])
> LogicalFilter(condition=[=($1, $3)])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[\{0}])
> LogicalTableScan(table=[[CATALOG, SALES, ORDERS]])
> LogicalSnapshot(period=[$cor0.PROCTIME])
> LogicalTableScan(table=[[CATALOG, SALES, PRODUCTS_TEMPORAL]])
> {code}
> If snapshot could be extended to support hint, it would make this
> optimization possible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5251) Support SQL hint for Snapshot
[ https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] lincoln lee updated CALCITE-5251: - Description: Current, `snapshot` does not support hint yet and this blocks hint propagation to the underlying temporal table. > Support SQL hint for Snapshot > - > > Key: CALCITE-5251 > URL: https://issues.apache.org/jira/browse/CALCITE-5251 > Project: Calcite > Issue Type: New Feature >Reporter: lincoln lee >Priority: Major > > Current, `snapshot` does not support hint yet and this blocks hint > propagation to the underlying temporal table. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5251) Support SQL hint for Snapshot
[ https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] lincoln lee updated CALCITE-5251: - Summary: Support SQL hint for Snapshot (was: Support SQL) > Support SQL hint for Snapshot > - > > Key: CALCITE-5251 > URL: https://issues.apache.org/jira/browse/CALCITE-5251 > Project: Calcite > Issue Type: New Feature >Reporter: lincoln lee >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5251) Support SQL
lincoln lee created CALCITE-5251: Summary: Support SQL Key: CALCITE-5251 URL: https://issues.apache.org/jira/browse/CALCITE-5251 Project: Calcite Issue Type: New Feature Reporter: lincoln lee -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-4611) Ambiguous column exception occurred when a table function has same column name in its input and output column list
lincoln lee created CALCITE-4611:
Summary: Ambiguous column exception occurred when a table function
has same column name in its input and output column list
Key: CALCITE-4611
URL: https://issues.apache.org/jira/browse/CALCITE-4611
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.26.0
Reporter: lincoln lee
{code}
@Test void testCollectionTableWithLateral4() {
sql("select T.* from dept, lateral table(DEDUP(deptno, name)) AS
T(name)").ok();
}
{code}
exception:
{code}
while converting DEDUP(`DEPTNO`, `NAME`)while converting DEDUP(`DEPTNO`,
`NAME`)java.lang.RuntimeException: while converting DEDUP(`DEPTNO`, `NAME`) at
org.apache.calcite.sql2rel.ReflectiveConvertletTable.lambda$registerOpTypeMethod$1(ReflectiveConvertletTable.java:127)
at
org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5098)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4374)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139) at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4961)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertCollectionTable(SqlToRelConverter.java:2555)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2190)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2093)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2050)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertJoin(SqlToRelConverter.java:2866)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2162)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2050)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:644)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3438)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:570)
at
org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:614)
at
org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:739)
at
org.apache.calcite.test.SqlToRelConverterTest$Sql.convertsTo(SqlToRelConverterTest.java:4192)
at
org.apache.calcite.test.SqlToRelConverterTest$Sql.ok(SqlToRelConverterTest.java:4184)
at
org.apache.calcite.test.SqlToRelConverterTest.testCollectionTableWithLateral4(SqlToRelConverterTest.java:1247)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
at
org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:62)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:43)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:35)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:202)
at
[jira] [Closed] (CALCITE-2023) Add SqlKind.AS to policy map of org.apache.calcite.plan.Strong due to NPE when apply FilterJoinRule
[
https://issues.apache.org/jira/browse/CALCITE-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
lincoln lee closed CALCITE-2023.
Resolution: Not A Problem
> Add SqlKind.AS to policy map of org.apache.calcite.plan.Strong due to NPE
> when apply FilterJoinRule
>
>
> Key: CALCITE-2023
> URL: https://issues.apache.org/jira/browse/CALCITE-2023
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: lincoln lee
>Priority: Minor
>
> Encounter a NPE when apply FilterJoinRule in a [use
> case|https://issues.apache.org/jira/browse/FLINK-7942] written in flink table
> api.
> A simple way to fix this is to change the calcite class
> {code}org.apache.calcite.plan.Strong{code} add an additional entry to the
> EnumMap in createPolicyMap method: {code}map.put(SqlKind.AS,
> Policy.AS_IS);{code}
> But I'm not sure if it is the right way, or there's other root cause?
> @julianhyde could you offer some advice?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4351) RelMdUtil#numDistinctVals always returns 0 for large inputs
[
https://issues.apache.org/jira/browse/CALCITE-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307648#comment-17307648
]
lincoln lee commented on CALCITE-4351:
--
[~fan_li_ya] When domainSize is in range (0, 1), the new formula will produce
Double.NaN result which may cause unexcepted exceptions，so at least we should
add protection for the code? {code}Math.log(1.0 - 1.0 / dSize){code}
> RelMdUtil#numDistinctVals always returns 0 for large inputs
> ---
>
> Key: CALCITE-4351
> URL: https://issues.apache.org/jira/browse/CALCITE-4351
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Caizhi Weng
>Priority: Major
>
> Previous implementation of {{RelMdUtil#numDistinctVals}} uses the
> approximation {{ln(1 + x) ~= x}} when {{x}} is small.
> However CALCITE-4132 remove this approximation to make the result more
> accurate. This causes the function to calculate an incorrect result for large
> inputs (for example, when {{domainSize = 1e18}} and {{numSelected = 1e10}}
> the result is 0) due to precision problems.
> What I would suggest is to treat small and large inputs in different ways.
> For small inputs we use the new, more precise function and for large inputs
> we use the old, approximated function.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
