[jira] [Comment Edited] (CALCITE-6129) SqlToRelConverter throws an exception when converting a NULL SqlLiteral
[
https://issues.apache.org/jira/browse/CALCITE-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788964#comment-17788964
]
Julian Hyde edited comment on CALCITE-6129 at 11/23/23 4:48 AM:
It's not that simple. Null literals do not have a type. SQL only allows null
literals in contexts where their type can be inferred.
was (Author: julianhyde):
Its not that simple null literals do not have a type sql only allows nulls
incontexts where their type can be inferred
> SqlToRelConverter throws an exception when converting a NULL SqlLiteral
> ---
>
> Key: CALCITE-6129
> URL: https://issues.apache.org/jira/browse/CALCITE-6129
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> The problem is in SqlNodeToRexConverterImpl.convertLiteral. This function
> attempts to handle NULL literals differently from all other literals:
> {code:java}
> final RexBuilder rexBuilder = cx.getRexBuilder();
> if (literal.getValue() == null) {
> RelDataType type = cx.getValidator().getValidatedNodeType(literal);
> return rexBuilder.makeNullLiteral(type);
> }
> switch (literal.getTypeName()) {
> ...
> {code}
> However, such a literal does *not* have a validated data type, so
> getValidatedNodeType will throw Util.needToImplement.
> The solution would be to handle NULL literals like all other literals and
> create a literal with a NULL type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6129) SqlToRelConverter throws an exception when converting a NULL SqlLiteral
[
https://issues.apache.org/jira/browse/CALCITE-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788964#comment-17788964
]
Julian Hyde commented on CALCITE-6129:
--
Its not that simple null literals do not have a type sql only allows nulls
incontexts where their type can be inferred
> SqlToRelConverter throws an exception when converting a NULL SqlLiteral
> ---
>
> Key: CALCITE-6129
> URL: https://issues.apache.org/jira/browse/CALCITE-6129
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> The problem is in SqlNodeToRexConverterImpl.convertLiteral. This function
> attempts to handle NULL literals differently from all other literals:
> {code:java}
> final RexBuilder rexBuilder = cx.getRexBuilder();
> if (literal.getValue() == null) {
> RelDataType type = cx.getValidator().getValidatedNodeType(literal);
> return rexBuilder.makeNullLiteral(type);
> }
> switch (literal.getTypeName()) {
> ...
> {code}
> However, such a literal does *not* have a validated data type, so
> getValidatedNodeType will throw Util.needToImplement.
> The solution would be to handle NULL literals like all other literals and
> create a literal with a NULL type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6129) SqlToRelConverter throws an exception when converting a NULL SqlLiteral
[
https://issues.apache.org/jira/browse/CALCITE-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu updated CALCITE-6129:
-
Description:
The problem is in SqlNodeToRexConverterImpl.convertLiteral. This function
attempts to handle NULL literals differently from all other literals:
{code:java}
final RexBuilder rexBuilder = cx.getRexBuilder();
if (literal.getValue() == null) {
RelDataType type = cx.getValidator().getValidatedNodeType(literal);
return rexBuilder.makeNullLiteral(type);
}
switch (literal.getTypeName()) {
...
{code}
However, such a literal does *not* have a validated data type, so
getValidatedNodeType will throw Util.needToImplement.
The solution would be to handle NULL literals like all other literals and
create a literal with a NULL type.
was:
The problem is in SqlNodeToRexConverterImpl.convertLiteral. This function
attempts to handle NULL literals differently from all other literals:
{code:java}
final RexBuilder rexBuilder = cx.getRexBuilder();
if (literal.getValue() == null) {
RelDataType type = cx.getValidator().getValidatedNodeType(literal);
return rexBuilder.makeNullLiteral(type);
}
switch (literal.getTypeName()) {
...
{code}
However, such a literal does *not* have a validated data type, to
getValidatedNodeType will throw Util.needToImplement.
The solution would be to handle NULL literals like all other literals and
create a literal with a NULL type.
> SqlToRelConverter throws an exception when converting a NULL SqlLiteral
> ---
>
> Key: CALCITE-6129
> URL: https://issues.apache.org/jira/browse/CALCITE-6129
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> The problem is in SqlNodeToRexConverterImpl.convertLiteral. This function
> attempts to handle NULL literals differently from all other literals:
> {code:java}
> final RexBuilder rexBuilder = cx.getRexBuilder();
> if (literal.getValue() == null) {
> RelDataType type = cx.getValidator().getValidatedNodeType(literal);
> return rexBuilder.makeNullLiteral(type);
> }
> switch (literal.getTypeName()) {
> ...
> {code}
> However, such a literal does *not* have a validated data type, so
> getValidatedNodeType will throw Util.needToImplement.
> The solution would be to handle NULL literals like all other literals and
> create a literal with a NULL type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6129) SqlToRelConverter throws an exception when converting a NULL SqlLiteral
Mihai Budiu created CALCITE-6129:
Summary: SqlToRelConverter throws an exception when converting a
NULL SqlLiteral
Key: CALCITE-6129
URL: https://issues.apache.org/jira/browse/CALCITE-6129
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0
Reporter: Mihai Budiu
The problem is in SqlNodeToRexConverterImpl.convertLiteral. This function
attempts to handle NULL literals differently from all other literals:
{code:java}
final RexBuilder rexBuilder = cx.getRexBuilder();
if (literal.getValue() == null) {
RelDataType type = cx.getValidator().getValidatedNodeType(literal);
return rexBuilder.makeNullLiteral(type);
}
switch (literal.getTypeName()) {
...
{code}
However, such a literal does *not* have a validated data type, to
getValidatedNodeType will throw Util.needToImplement.
The solution would be to handle NULL literals like all other literals and
create a literal with a NULL type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5164) Planner#parser can't parse TIMESTAMP() function
[
https://issues.apache.org/jira/browse/CALCITE-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5164.
--
Fix Version/s: 1.34.0
Resolution: Duplicate
I agree. I'm closing it as a duplicate.
> Planner#parser can't parse TIMESTAMP() function
> ---
>
> Key: CALCITE-5164
> URL: https://issues.apache.org/jira/browse/CALCITE-5164
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.30.0
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Fix For: 1.34.0
>
>
> Both core and babel will parse fail.
> {code:java}
> FrameworkConfig coreConfig = Frameworks.newConfigBuilder().build();
> Planner corePlanner = Frameworks.getPlanner(coreConfig);
> corePlanner.parse("SELECT TIMESTAMP('2022-05-21 08:00:00'");
> // Caused by: org.apache.calcite.sql.parser.babel.ParseException:
> Incorrect syntax near the keyword 'TIMESTAMP' at line 1, column 8.
> FrameworkConfig babelConfig = Frameworks.newConfigBuilder()
> .parserConfig(SqlParser.Config.DEFAULT.withParserFactory(
> SqlBabelParserImpl.FACTORY))
> .build();
> Planner babelPlanner = Frameworks.getPlanner(babelConfig);
> babelPlanner.parse("SELECT TIMESTAMP('2022-05-21 08:00:00'");
> // Caused by: org.apache.calcite.sql.parser.babel.ParseException:
> Incorrect syntax near the keyword 'TIMESTAMP' at line 1, column 8
> {code}
> Here are some databases that support TIMESTAMP function.
> - MySQL:
> [https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_timestamp]
> {code:java}
> select timestamp('2022-05-21 08:00:00')
> // result
> timestamp('2022-05-21 08:00:00')
> 2022-05-21 08:00:00
> {code}
> - Derby: [https://docs.oracle.com/javadb/10.6.2.1/ref/rreftimestampfunc.html]
> Also, here are some databases that not support TIMESTAMP function:
> - Oracle:
> [https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm]
> {code:java}
> select timestamp('2022-05-21 08:00:00')
> //ORA-00923: FROM keyword not found where expected
> {code}
> - SQL Server:
> [https://docs.microsoft.com/en-us/sql/t-sql/functions/date-and-time-data-types-and-functions-transact-sql?view=sql-server-ver15]
> {code:java}
> select timestamp('2022-05-21 08:00:00')
> // Msg 195 Level 15 State 10 Line 1
> // 'timestamp' is not a recognized built-in function name.{code}
> Is it necessary for us to support it in babel module?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6128) RelBuilder.limit should apply offset and fetch to previous Sort operator, if possible
[
https://issues.apache.org/jira/browse/CALCITE-6128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6128:
-
Description:
The {{RelBuilder.limit(offset, fetch)}} method should apply {{offset}} and
{{fetch}} to the previous {{Sort}} operator, if possible. If I call
{{RelBuilder.sortLimit}} to create a {{Sort}} with an offset but no fetch, then
call {{RelBuilder.limit(0, fetch)}} to set a fetch, it currently creates two
{{LogicalSort}} nodes but should just modify the {{fetch}} of the existing
{{{}LogicalSort{}}}.
For example,
{code:java}
b.scan("EMP")
.sortLimit(2, -1, b.field("DEPTNO"))
.limit(-1, 3)
.build()
{code}
should generate the plan
{noformat}
LogicalSort(sort0=[$7], dir0=[ASC], offset=[2], fetch=[3])
LogicalTableScan(table=[[scott, EMP]])
{noformat}
but instead generates
{noformat}
LogicalSort(fetch=[3])
LogicalSort(sort0=[$7], dir0=[ASC], offset=[2])
LogicalTableScan(table=[[scott, EMP]])
{noformat}
Similarly any other {{RelBuilder}} methods that allow creating a {{Sort}} with
or without {{offset}} and {{fetch}}.
was:
The {{RelBuilder.sortLimit}} method should compose offset and fetch. If I call
{{RelBuilder.sort}} to set sort with an offset, then call
{{RelBuilder.offsetLimit}} to set a fetch, it currently creates two
{{LogicalSort}} nodes but should create just one.
For example,
{code:java}
b.scan("EMP")
.sortLimit(2, -1, b.field("DEPTNO"))
.limit(-1, 3)
.build()
{code}
should generate the plan
{noformat}
LogicalSort(sort0=[$7], dir0=[ASC], offset=[2], fetch=[3])
LogicalTableScan(table=[[scott, EMP]])
{noformat}
but instead generates
{noformat}
LogicalSort(fetch=[3])
LogicalSort(sort0=[$7], dir0=[ASC], offset=[2])
LogicalTableScan(table=[[scott, EMP]])
{noformat}
> RelBuilder.limit should apply offset and fetch to previous Sort operator, if
> possible
> -
>
> Key: CALCITE-6128
> URL: https://issues.apache.org/jira/browse/CALCITE-6128
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The {{RelBuilder.limit(offset, fetch)}} method should apply {{offset}} and
> {{fetch}} to the previous {{Sort}} operator, if possible. If I call
> {{RelBuilder.sortLimit}} to create a {{Sort}} with an offset but no fetch,
> then call {{RelBuilder.limit(0, fetch)}} to set a fetch, it currently creates
> two {{LogicalSort}} nodes but should just modify the {{fetch}} of the
> existing {{{}LogicalSort{}}}.
> For example,
> {code:java}
> b.scan("EMP")
> .sortLimit(2, -1, b.field("DEPTNO"))
> .limit(-1, 3)
> .build()
> {code}
> should generate the plan
> {noformat}
> LogicalSort(sort0=[$7], dir0=[ASC], offset=[2], fetch=[3])
> LogicalTableScan(table=[[scott, EMP]])
> {noformat}
> but instead generates
> {noformat}
> LogicalSort(fetch=[3])
> LogicalSort(sort0=[$7], dir0=[ASC], offset=[2])
> LogicalTableScan(table=[[scott, EMP]])
> {noformat}
> Similarly any other {{RelBuilder}} methods that allow creating a {{Sort}}
> with or without {{offset}} and {{fetch}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6128) RelBuilder.limit should apply offset and fetch to previous Sort operator, if possible
[
https://issues.apache.org/jira/browse/CALCITE-6128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6128:
-
Summary: RelBuilder.limit should apply offset and fetch to previous Sort
operator, if possible (was: RelBuilder.sortLimit should compose offset and
fetch)
> RelBuilder.limit should apply offset and fetch to previous Sort operator, if
> possible
> -
>
> Key: CALCITE-6128
> URL: https://issues.apache.org/jira/browse/CALCITE-6128
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The {{RelBuilder.sortLimit}} method should compose offset and fetch. If I
> call {{RelBuilder.sort}} to set sort with an offset, then call
> {{RelBuilder.offsetLimit}} to set a fetch, it currently creates two
> {{LogicalSort}} nodes but should create just one.
> For example,
> {code:java}
> b.scan("EMP")
> .sortLimit(2, -1, b.field("DEPTNO"))
> .limit(-1, 3)
> .build()
> {code}
> should generate the plan
> {noformat}
> LogicalSort(sort0=[$7], dir0=[ASC], offset=[2], fetch=[3])
> LogicalTableScan(table=[[scott, EMP]])
> {noformat}
> but instead generates
> {noformat}
> LogicalSort(fetch=[3])
> LogicalSort(sort0=[$7], dir0=[ASC], offset=[2])
> LogicalTableScan(table=[[scott, EMP]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5164) Planner#parser can't parse TIMESTAMP() function
[
https://issues.apache.org/jira/browse/CALCITE-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788914#comment-17788914
]
Will Noble commented on CALCITE-5164:
-
If I'm not mistaken, I believe this ticket is now obsolete since CALCITE-5508
is resolved.
> Planner#parser can't parse TIMESTAMP() function
> ---
>
> Key: CALCITE-5164
> URL: https://issues.apache.org/jira/browse/CALCITE-5164
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.30.0
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
>
> Both core and babel will parse fail.
> {code:java}
> FrameworkConfig coreConfig = Frameworks.newConfigBuilder().build();
> Planner corePlanner = Frameworks.getPlanner(coreConfig);
> corePlanner.parse("SELECT TIMESTAMP('2022-05-21 08:00:00'");
> // Caused by: org.apache.calcite.sql.parser.babel.ParseException:
> Incorrect syntax near the keyword 'TIMESTAMP' at line 1, column 8.
> FrameworkConfig babelConfig = Frameworks.newConfigBuilder()
> .parserConfig(SqlParser.Config.DEFAULT.withParserFactory(
> SqlBabelParserImpl.FACTORY))
> .build();
> Planner babelPlanner = Frameworks.getPlanner(babelConfig);
> babelPlanner.parse("SELECT TIMESTAMP('2022-05-21 08:00:00'");
> // Caused by: org.apache.calcite.sql.parser.babel.ParseException:
> Incorrect syntax near the keyword 'TIMESTAMP' at line 1, column 8
> {code}
> Here are some databases that support TIMESTAMP function.
> - MySQL:
> [https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_timestamp]
> {code:java}
> select timestamp('2022-05-21 08:00:00')
> // result
> timestamp('2022-05-21 08:00:00')
> 2022-05-21 08:00:00
> {code}
> - Derby: [https://docs.oracle.com/javadb/10.6.2.1/ref/rreftimestampfunc.html]
> Also, here are some databases that not support TIMESTAMP function:
> - Oracle:
> [https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm]
> {code:java}
> select timestamp('2022-05-21 08:00:00')
> //ORA-00923: FROM keyword not found where expected
> {code}
> - SQL Server:
> [https://docs.microsoft.com/en-us/sql/t-sql/functions/date-and-time-data-types-and-functions-transact-sql?view=sql-server-ver15]
> {code:java}
> select timestamp('2022-05-21 08:00:00')
> // Msg 195 Level 15 State 10 Line 1
> // 'timestamp' is not a recognized built-in function name.{code}
> Is it necessary for us to support it in babel module?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6128) RelBuilder.sortLimit should compose offset and fetch
[
https://issues.apache.org/jira/browse/CALCITE-6128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6128:
Labels: pull-request-available (was: )
> RelBuilder.sortLimit should compose offset and fetch
>
>
> Key: CALCITE-6128
> URL: https://issues.apache.org/jira/browse/CALCITE-6128
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The {{RelBuilder.sortLimit}} method should compose offset and fetch. If I
> call {{RelBuilder.sort}} to set sort with an offset, then call
> {{RelBuilder.offsetLimit}} to set a fetch, it currently creates two
> {{LogicalSort}} nodes but should create just one.
> For example,
> {code:java}
> b.scan("EMP")
> .sortLimit(2, -1, b.field("DEPTNO"))
> .limit(-1, 3)
> .build()
> {code}
> should generate the plan
> {noformat}
> LogicalSort(sort0=[$7], dir0=[ASC], offset=[2], fetch=[3])
> LogicalTableScan(table=[[scott, EMP]])
> {noformat}
> but instead generates
> {noformat}
> LogicalSort(fetch=[3])
> LogicalSort(sort0=[$7], dir0=[ASC], offset=[2])
> LogicalTableScan(table=[[scott, EMP]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
