[jira] [Resolved] (CALCITE-5826) Add FIND_IN_SET function (enabled in Hive and Spark library)
[
https://issues.apache.org/jira/browse/CALCITE-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5826.
-
Resolution: Fixed
> Add FIND_IN_SET function (enabled in Hive and Spark library)
>
>
> Key: CALCITE-5826
> URL: https://issues.apache.org/jira/browse/CALCITE-5826
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Add FIND_IN_SET function (enabled in Hive and Spark library):
>
> FIND_IN_SET(str, str_array) - find_in_set(str, str_array) - Returns the index
> (1-based) of the given string ({{{}str{}}}) in the comma-delimited list
> ({{{}str_array{}}}). Returns 0, if the string was not found or if the given
> string ({{{}str{}}}) contains a comma.
>
> See more details in
> [Hive|https://cwiki.apache.org/confluence/display/hive/languagemanual+udf#LanguageManualUDF-StringFunctions]
> and
> [Spark|https://spark.apache.org/docs/latest/api/sql/index.html#find_in_set]
> doc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5826) Add FIND_IN_SET function (enabled in Hive and Spark library)
[
https://issues.apache.org/jira/browse/CALCITE-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781596#comment-17781596
]
Jiajun Xie commented on CALCITE-5826:
-
Fixed in
[2ddc605|https://github.com/apache/calcite/commit/2ddc6053b55147622f4a4642786d36403ce7f49a].
Thanks for the PR.[~Runking]
Thanks for the review [~shenlang] , [~mbudiu].
> Add FIND_IN_SET function (enabled in Hive and Spark library)
>
>
> Key: CALCITE-5826
> URL: https://issues.apache.org/jira/browse/CALCITE-5826
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Add FIND_IN_SET function (enabled in Hive and Spark library):
>
> FIND_IN_SET(str, str_array) - find_in_set(str, str_array) - Returns the index
> (1-based) of the given string ({{{}str{}}}) in the comma-delimited list
> ({{{}str_array{}}}). Returns 0, if the string was not found or if the given
> string ({{{}str{}}}) contains a comma.
>
> See more details in
> [Hive|https://cwiki.apache.org/confluence/display/hive/languagemanual+udf#LanguageManualUDF-StringFunctions]
> and
> [Spark|https://spark.apache.org/docs/latest/api/sql/index.html#find_in_set]
> doc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6037) The function category of ARRAY/EXTRACT_VALUE/XML_TRANSFORM/EXTRACT_XML/EXISTSNODE is incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie resolved CALCITE-6037. - Resolution: Fixed > The function category of > ARRAY/EXTRACT_VALUE/XML_TRANSFORM/EXTRACT_XML/EXISTSNODE is incorrect > -- > > Key: CALCITE-6037 > URL: https://issues.apache.org/jira/browse/CALCITE-6037 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Ran Tao >Assignee: Ran Tao >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > Currently some functions do not specify a category name. > It will cause the error function category: > > ||function name||current category||desired category|| > |ARRAY (Spark)|Numeric|System| > |EXTRACT_VALUE (MySQL)|Numeric|String| > |XML_TRANSFORM (Oracle)|Numeric|String| > |EXTRACT_XML (Oracle)|Numeric|String| > |EXISTSNODE (Oracle)|Numeric|String| > the definition of function category in ANSI-SQL (not very sure this is the > sql standard, but the implementation of calcite is similar to it) can be > found at: > [https://www.oreilly.com/library/view/sql-in-a/9780596155322/ch04s04.html.|http://users.atw.hu/sqlnut/sqlnut2-chp-4-sect-4.html#sqlnut2-CHP-4-SECT-4.1] > Generally speaking, these functions (except ARRAY) process XML text and > conform to the definition of String category rather than Numeric. > btw, because they use a simplified constructor of SqlBasicFunction, the > function category is always set to Numeric. We need to set the desired > function category. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6037) The function category of ARRAY/EXTRACT_VALUE/XML_TRANSFORM/EXTRACT_XML/EXISTSNODE is incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780786#comment-17780786 ] Jiajun Xie commented on CALCITE-6037: - Fixed in [edec1c3|https://github.com/apache/calcite/commit/edec1c3891b587aa56c1da09a3dd810f4b7adcc1]. Thanks for the PR [~taoran] . Thanks for the review [~shenlang] , [~mbudiu] . > The function category of > ARRAY/EXTRACT_VALUE/XML_TRANSFORM/EXTRACT_XML/EXISTSNODE is incorrect > -- > > Key: CALCITE-6037 > URL: https://issues.apache.org/jira/browse/CALCITE-6037 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Ran Tao >Assignee: Ran Tao >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > Currently some functions do not specify a category name. > It will cause the error function category: > > ||function name||current category||desired category|| > |ARRAY (Spark)|Numeric|System| > |EXTRACT_VALUE (MySQL)|Numeric|String| > |XML_TRANSFORM (Oracle)|Numeric|String| > |EXTRACT_XML (Oracle)|Numeric|String| > |EXISTSNODE (Oracle)|Numeric|String| > the definition of function category in ANSI-SQL (not very sure this is the > sql standard, but the implementation of calcite is similar to it) can be > found at: > [https://www.oreilly.com/library/view/sql-in-a/9780596155322/ch04s04.html.|http://users.atw.hu/sqlnut/sqlnut2-chp-4-sect-4.html#sqlnut2-CHP-4-SECT-4.1] > Generally speaking, these functions (except ARRAY) process XML text and > conform to the definition of String category rather than Numeric. > btw, because they use a simplified constructor of SqlBasicFunction, the > function category is always set to Numeric. We need to set the desired > function category. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5825) Add URL_ENCODE and URL_DECODE function (enabled in Spark library)
[
https://issues.apache.org/jira/browse/CALCITE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5825.
-
Resolution: Fixed
> Add URL_ENCODE and URL_DECODE function (enabled in Spark library)
> -
>
> Key: CALCITE-5825
> URL: https://issues.apache.org/jira/browse/CALCITE-5825
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Add URL_ENCODE and URL_DECODE function (enabled in Spark library):
> * URL_ENCODE(str) - Translates a string into
> 'application/x-www-form-urlencoded' format using a specific encoding scheme.
> See more details in
> [Spark|https://spark.apache.org/docs/latest/api/sql/index.html#url_encode]
> doc.
> * URL_DECODE(str) - Decodes a {{str}} in 'application/x-www-form-urlencoded'
> format using a specific encoding scheme. See more details in
> [Spark|https://spark.apache.org/docs/latest/api/sql/index.html#url_decode]
> doc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5825) Add URL_ENCODE and URL_DECODE function (enabled in Spark library)
[
https://issues.apache.org/jira/browse/CALCITE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780310#comment-17780310
]
Jiajun Xie commented on CALCITE-5825:
-
Fixed in
[ad2e843|https://github.com/apache/calcite/commit/ad2e843c5d9b3bec001d22e680ebe6b5de4e2078].
Thanks for the PR.[~Runking]
Thanks for your review [~shenlang] , [~mbudiu] .
> Add URL_ENCODE and URL_DECODE function (enabled in Spark library)
> -
>
> Key: CALCITE-5825
> URL: https://issues.apache.org/jira/browse/CALCITE-5825
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Add URL_ENCODE and URL_DECODE function (enabled in Spark library):
> * URL_ENCODE(str) - Translates a string into
> 'application/x-www-form-urlencoded' format using a specific encoding scheme.
> See more details in
> [Spark|https://spark.apache.org/docs/latest/api/sql/index.html#url_encode]
> doc.
> * URL_DECODE(str) - Decodes a {{str}} in 'application/x-www-form-urlencoded'
> format using a specific encoding scheme. See more details in
> [Spark|https://spark.apache.org/docs/latest/api/sql/index.html#url_decode]
> doc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6038) Remove 'ORDER BY ... LIMIT n' when input has at most one row, n >= 1, and there is no 'OFFSET' clause
[
https://issues.apache.org/jira/browse/CALCITE-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778896#comment-17778896
]
Jiajun Xie commented on CALCITE-6038:
-
Sorry, [~shenlang]
I've been too busy lately to review your review request.
Just left a comment, let's work hard to resolve it at 1.36 version.
> Remove 'ORDER BY ... LIMIT n' when input has at most one row, n >= 1, and
> there is no 'OFFSET' clause
> -
>
> Key: CALCITE-6038
> URL: https://issues.apache.org/jira/browse/CALCITE-6038
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> When a Sort represents 'Order By x Limit n',and its input is guaranteed that
> is at most one row,we could remove this Sort.
> For example,the sql:
> {code:java}
> SELECT count(*) FROM orders ORDER BY 1 LIMIT 10 {code}
> because the `SELECT count(*) FROM orders ` row count is 1, it is at most one
> row,then we could remove `ORDER BY 1 LIMIT 10 `,after the optimization,the
> sql is :
> {code:java}
> SELECT count(*) FROM orders {code}
> Above logic are same as Presto/Trino's
> [RemoveRedundantTopN|https://github.com/prestodb/presto/blob/21ab1ea2425e4bc65532ab156c60333e5a72dd09/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantTopN.java#L27C1-L28C34]
> rule:
> This JIRA is enhancement for {-}CALCITE-5994{-}, in -CALCITE-5994- ,we
> restrict Sort must be pure Order(Offset and Limit is null),after this
> jira,this optimization could be applied to 'Order By x' Or 'Order By x Limit
> n'.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-4455) Babel parser support Spark INSERT OVERWRITE TABLE/DIRECTORY statement
[
https://issues.apache.org/jira/browse/CALCITE-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-4455:
Fix Version/s: 1.36.0
> Babel parser support Spark INSERT OVERWRITE TABLE/DIRECTORY statement
> -
>
> Key: CALCITE-4455
> URL: https://issues.apache.org/jira/browse/CALCITE-4455
> Project: Calcite
> Issue Type: Sub-task
> Components: spark
>Reporter: shradha
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Spark has [INSERT OVERWRITE TABLE
> statement|https://spark.apache.org/docs/3.1.2/sql-ref-syntax-dml-insert-overwrite-table.html]
> and [INSERT OVERWRITE DIRECTORY
> statement|https://spark.apache.org/docs/3.1.2/sql-ref-syntax-dml-insert-overwrite-directory.html].
>
> We can support part of their grammar, here is syntax that babel parser used:
> - INSERT OVERWRITE TABLE
> -- Syntax
> {code:java}
> INSERT OVERWRITE TABLE table_identifier [ partition_spec [ IF NOT EXISTS ] ]
> [ ( column_list ) ]
> { VALUES ( { value | NULL } [ , ... ] ) [ , ( ... ) ] | query } {code}
> -- Example
> {code:java}
> -- Insert Using a SELECT Statement
> INSERT OVERWRITE TABLE students PARTITION (student_id = 22)
> SELECT name, address FROM persons WHERE name = "Dora Williams";
> -- Insert Using a SELECT Statement with column list and omit partition
> INSERT OVERWRITE TABLE target (c1) SELECT * FROM source
> -- Insert Using a VALUES Clause
> INSERT OVERWRITE TABLE students
> VALUES ('Ashua Hill', '456 Erica Ct, Cupertino', 11),
>('Brian Reed', '723 Kern Ave, Palo Alto', 22); {code}
> - INSERT OVERWRITE DIRECTORY
> -- Syntax
> {code:java}
> INSERT OVERWRITE [ LOCAL ] DIRECTORY directory_path
> USING file_format [ OPTIONS ( key = val [ , ... ] ) ]
> { VALUES ( { value | NULL } [ , ... ] ) [ , ( ... ) ] | query }{code}
> -- Example
> {code:java}
> INSERT OVERWRITE DIRECTORY '/tmp/destination'
> USING parquet
> OPTIONS (col1=1, col2=2, col3='test')
> SELECT * FROM test_table;
> -- omit options
> INSERT OVERWRITE DIRECTORY '/tmp/destination'
> USING parquet
> SELECT * FROM test_table;{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6022) Support "CREATE TABLE ... LIKE" DDL in server module
[
https://issues.apache.org/jira/browse/CALCITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-6022.
-
Resolution: Fixed
> Support "CREATE TABLE ... LIKE" DDL in server module
>
>
> Key: CALCITE-6022
> URL: https://issues.apache.org/jira/browse/CALCITE-6022
> Project: Calcite
> Issue Type: New Feature
> Components: server
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> "CREATE TABLE ... LIKE" is SQL standard syntax, and some other dbms(mysql,
> postgresql, sparksql) support it. So I think it is worth implementing.
> Syntax:
> {code:sql}
> CREATE TABLE [IF NOT EXISTS] table_name
> LIKE source_table [ like_option ... ]{code}
> And for the `like_option`, I think the syntax of postgreSQL is more flexible
> and powerful, and I believe it is reasonable to be similar to postgreSQL. But
> there are not so many attributes in calcite, just keep GENERATED, DEFAULTS
> and ALL.
> {code:sql}
> { INCLUDING | EXCLUDING } { GENERATED | DEFAULTS | ALL }{code}
> Some related link:
> [https://www.postgresql.org/docs/current/sql-createtable.html]
> [https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#table%20definition]
> [https://dev.mysql.com/doc/refman/8.0/en/create-table-like.html]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6022) Support "CREATE TABLE ... LIKE" DDL in server module
[
https://issues.apache.org/jira/browse/CALCITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776968#comment-17776968
]
Jiajun Xie commented on CALCITE-6022:
-
Fixed in
[23b7931|https://github.com/apache/calcite/commit/23b7931c3e516bdb6cfedda956213f7fe06c6b24].
Thanks for the PR [~hongyuguo].
> Support "CREATE TABLE ... LIKE" DDL in server module
>
>
> Key: CALCITE-6022
> URL: https://issues.apache.org/jira/browse/CALCITE-6022
> Project: Calcite
> Issue Type: New Feature
> Components: server
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> "CREATE TABLE ... LIKE" is SQL standard syntax, and some other dbms(mysql,
> postgresql, sparksql) support it. So I think it is worth implementing.
> Syntax:
> {code:sql}
> CREATE TABLE [IF NOT EXISTS] table_name
> LIKE source_table [ like_option ... ]{code}
> And for the `like_option`, I think the syntax of postgreSQL is more flexible
> and powerful, and I believe it is reasonable to be similar to postgreSQL. But
> there are not so many attributes in calcite, just keep GENERATED, DEFAULTS
> and ALL.
> {code:sql}
> { INCLUDING | EXCLUDING } { GENERATED | DEFAULTS | ALL }{code}
> Some related link:
> [https://www.postgresql.org/docs/current/sql-createtable.html]
> [https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#table%20definition]
> [https://dev.mysql.com/doc/refman/8.0/en/create-table-like.html]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5570) Support nested map type for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17775190#comment-17775190
]
Jiajun Xie commented on CALCITE-5570:
-
[~MasseGuillaume] , Thank you for your notification.
Would you please review it: https://github.com/apache/calcite/pull/3469
> Support nested map type for SqlDataTypeSpec
> ---
>
> Key: CALCITE-5570
> URL: https://issues.apache.org/jira/browse/CALCITE-5570
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There was added a similar support for arrays/multisets at
> https://issues.apache.org/jira/browse/CALCITE-3250
> however there is no support for maps so far.
> The issue is to add such support.
>
> I think I'd like to clarify is syntax for maps since it has 2 internal
> subtypes for keys and values may be something similar to ROW with delimiter
> like
> {code:sql}
> SELECT CAST(NULL AS MAP(INT, INT));
> -- or with square brackets similar to map constructor
> SELECT CAST(NULL AS MAP[INT, INT]);
> -- or with angle (Flink syntax)
> SELECT CAST(NULL AS MAP);
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6049) Exception when using division with dynamic param
[
https://issues.apache.org/jira/browse/CALCITE-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774885#comment-17774885
]
Jiajun Xie commented on CALCITE-6049:
-
- Before 1.22, here is the validate SqlNode for `{color:#172b4d}select (1 *
?)/2 as t{color}`
{code:java}
SELECT 1 * CAST(? AS DECIMAL(19, 19)) / 2 AS `T` {code}
- From 1.22, we forbid implicit type coercion for dynamic param in CALCITE-3672
You can see the code:
https://github.com/danny0405/calcite/blob/081e7a3d4549315ea8af52beb5f5d86158f17dbf/core/src/main/java/org/apache/calcite/sql/validate/implicit/AbstractTypeCoercion.java#L98C17-L98C17
> Exception when using division with dynamic param
>
>
> Key: CALCITE-6049
> URL: https://issues.apache.org/jira/browse/CALCITE-6049
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Soumyava Das
>Priority: Major
>
> I tried the following test case
>
> {code:java}
> @Test void testDynamicParams()
> {
>sql("select (1 * ?) as t").ok();
>sql("select (1 * ?)/2 as t").ok();
> } {code}
> in SqlValidatorTest. The first query compiles fine but the second one where I
> use a division throws the following message
> {code:java}
> org.apache.calcite.sql.validate.SqlValidatorException: Cannot apply '*' to
> arguments of type ' * '. Supported form(s): ' *
> '
> ' * '
> ' * '
> 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:505)
> at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:599)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:945)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:930)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5464)
> at
> org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:403)
> at
> org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:127)
> at
> org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkOperandTypes(FamilyOperandTypeChecker.java:161)
> at
> org.apache.calcite.sql.type.CompositeOperandTypeChecker.check(CompositeOperandTypeChecker.java:345)
> at
> org.apache.calcite.sql.type.CompositeOperandTypeChecker.checkOperandTypes(CompositeOperandTypeChecker.java:275)
> at org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:759)
> at org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:499)
> at org.apache.calcite.sql.SqlOperator.deriveType(SqlOperator.java:605)
> at
> org.apache.calcite.sql.SqlBinaryOperator.deriveType(SqlBinaryOperator.java:178)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6521)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6508)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1897)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1882)
> at org.apache.calcite.sql.type.SqlTypeUtil.deriveType(SqlTypeUtil.java:200)
> at org.apache.calcite.sql.type.InferTypes.lambda$static$0(InferTypes.java:47)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:2084)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:2072)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:487)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4608)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3780)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:61)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1135)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1106)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:282)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1081)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:787)
> at
>
[jira] [Resolved] (CALCITE-6006) RelToSqlConverter loses charset information
[ https://issues.apache.org/jira/browse/CALCITE-6006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie resolved CALCITE-6006. - Resolution: Fixed > RelToSqlConverter loses charset information > > > Key: CALCITE-6006 > URL: https://issues.apache.org/jira/browse/CALCITE-6006 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > This is a bug in SqlImplementor, when it calls SqlLiteral.createCharString it > does not pass any information about the charset of the source string. So a > string that looks like _UTF8'...' is converted to a string without the > charset in the generated SQL. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6006) RelToSqlConverter loses charset information
[ https://issues.apache.org/jira/browse/CALCITE-6006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774757#comment-17774757 ] Jiajun Xie commented on CALCITE-6006: - Fixed in [485a5d0.|https://github.com/apache/calcite/commit/485a5d0ae3274a83a36788290b3bdc4d973387b4] Thanks for the PR [~mbudiu]. > RelToSqlConverter loses charset information > > > Key: CALCITE-6006 > URL: https://issues.apache.org/jira/browse/CALCITE-6006 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > This is a bug in SqlImplementor, when it calls SqlLiteral.createCharString it > does not pass any information about the charset of the source string. So a > string that looks like _UTF8'...' is converted to a string without the > charset in the generated SQL. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6009) Add optimization to remove redundant LIMIT that is more than input row count
[
https://issues.apache.org/jira/browse/CALCITE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-6009.
-
Resolution: Fixed
> Add optimization to remove redundant LIMIT that is more than input row count
>
>
> Key: CALCITE-6009
> URL: https://issues.apache.org/jira/browse/CALCITE-6009
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> In calcite,Limit would be represented by Sort,such as `LogicalSort[fetch =
> 5]`.
> When the Limit' source row number is less than the Limit's fetch,we could
> remove the the redundant Limit.
> For example:
> {code:java}
> SELECT * FROM (VALUES 1,2,3,4,5,6) AS t1 LIMIT 10 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[10])
> LogicalProject(t1=[$0])
> LogicalValues(tuples=[[{ 1 }, { 2 }, { 3 }, { 4 }, { 5 }, { 6 }]]) {code}
> Because the Limit's source max row number is 6,the Limit's fetch is 10,so we
> could remove the redundant Limit.
> Another example is :
> {code:java}
> SELECT count(*) FROM orders LIMIT 2 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[2])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because Limit's source max row number is 1,the Limit's fetch is 2, so we
> could remove the redundant Limit.
> The logic is same as presto's RemoveRedundantLimit
> rule:https://github.com/prestodb/presto/blob/50fbc07111ecca60a1a5e62755f095fa204120d0/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantLimit.java#L27
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6009) Add optimization to remove redundant LIMIT that is more than input row count
[
https://issues.apache.org/jira/browse/CALCITE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771377#comment-17771377
]
Jiajun Xie edited comment on CALCITE-6009 at 10/3/23 8:25 AM:
--
Fixed in
[87cdfd9|https://github.com/apache/calcite/commit/87cdfd97f0948443f7199c9f5b694feb8808caeb].
Thanks for the PR [~shenlang] .
was (Author: jiajunbernoulli):
Fixed in
[87cdfd9|https://github.com/apache/calcite/commit/87cdfd97f0948443f7199c9f5b694feb8808caeb].
Thanks fro the PR [~shenlang] .
> Add optimization to remove redundant LIMIT that is more than input row count
>
>
> Key: CALCITE-6009
> URL: https://issues.apache.org/jira/browse/CALCITE-6009
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> In calcite,Limit would be represented by Sort,such as `LogicalSort[fetch =
> 5]`.
> When the Limit' source row number is less than the Limit's fetch,we could
> remove the the redundant Limit.
> For example:
> {code:java}
> SELECT * FROM (VALUES 1,2,3,4,5,6) AS t1 LIMIT 10 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[10])
> LogicalProject(t1=[$0])
> LogicalValues(tuples=[[{ 1 }, { 2 }, { 3 }, { 4 }, { 5 }, { 6 }]]) {code}
> Because the Limit's source max row number is 6,the Limit's fetch is 10,so we
> could remove the redundant Limit.
> Another example is :
> {code:java}
> SELECT count(*) FROM orders LIMIT 2 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[2])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because Limit's source max row number is 1,the Limit's fetch is 2, so we
> could remove the redundant Limit.
> The logic is same as presto's RemoveRedundantLimit
> rule:https://github.com/prestodb/presto/blob/50fbc07111ecca60a1a5e62755f095fa204120d0/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantLimit.java#L27
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6009) Add optimization to remove redundant LIMIT that is more than input row count
[
https://issues.apache.org/jira/browse/CALCITE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771377#comment-17771377
]
Jiajun Xie commented on CALCITE-6009:
-
Fixed in
[87cdfd9|https://github.com/apache/calcite/commit/87cdfd97f0948443f7199c9f5b694feb8808caeb].
Thanks fro the PR [~shenlang] .
> Add optimization to remove redundant LIMIT that is more than input row count
>
>
> Key: CALCITE-6009
> URL: https://issues.apache.org/jira/browse/CALCITE-6009
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> In calcite,Limit would be represented by Sort,such as `LogicalSort[fetch =
> 5]`.
> When the Limit' source row number is less than the Limit's fetch,we could
> remove the the redundant Limit.
> For example:
> {code:java}
> SELECT * FROM (VALUES 1,2,3,4,5,6) AS t1 LIMIT 10 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[10])
> LogicalProject(t1=[$0])
> LogicalValues(tuples=[[{ 1 }, { 2 }, { 3 }, { 4 }, { 5 }, { 6 }]]) {code}
> Because the Limit's source max row number is 6,the Limit's fetch is 10,so we
> could remove the redundant Limit.
> Another example is :
> {code:java}
> SELECT count(*) FROM orders LIMIT 2 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[2])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because Limit's source max row number is 1,the Limit's fetch is 2, so we
> could remove the redundant Limit.
> The logic is same as presto's RemoveRedundantLimit
> rule:https://github.com/prestodb/presto/blob/50fbc07111ecca60a1a5e62755f095fa204120d0/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantLimit.java#L27
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-4455) Babel parser support Spark INSERT OVERWRITE TABLE/DIRECTORY statement
[
https://issues.apache.org/jira/browse/CALCITE-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770990#comment-17770990
]
Jiajun Xie commented on CALCITE-4455:
-
Would anyone review it?
https://github.com/apache/calcite/pull/2949/files
> Babel parser support Spark INSERT OVERWRITE TABLE/DIRECTORY statement
> -
>
> Key: CALCITE-4455
> URL: https://issues.apache.org/jira/browse/CALCITE-4455
> Project: Calcite
> Issue Type: Sub-task
> Components: spark
>Reporter: shradha
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Spark has [INSERT OVERWRITE TABLE
> statement|https://spark.apache.org/docs/3.1.2/sql-ref-syntax-dml-insert-overwrite-table.html]
> and [INSERT OVERWRITE DIRECTORY
> statement|https://spark.apache.org/docs/3.1.2/sql-ref-syntax-dml-insert-overwrite-directory.html].
>
> We can support part of their grammar, here is syntax that babel parser used:
> - INSERT OVERWRITE TABLE
> -- Syntax
> {code:java}
> INSERT OVERWRITE TABLE table_identifier [ partition_spec [ IF NOT EXISTS ] ]
> [ ( column_list ) ]
> { VALUES ( { value | NULL } [ , ... ] ) [ , ( ... ) ] | query } {code}
> -- Example
> {code:java}
> -- Insert Using a SELECT Statement
> INSERT OVERWRITE TABLE students PARTITION (student_id = 22)
> SELECT name, address FROM persons WHERE name = "Dora Williams";
> -- Insert Using a SELECT Statement with column list and omit partition
> INSERT OVERWRITE TABLE target (c1) SELECT * FROM source
> -- Insert Using a VALUES Clause
> INSERT OVERWRITE TABLE students
> VALUES ('Ashua Hill', '456 Erica Ct, Cupertino', 11),
>('Brian Reed', '723 Kern Ave, Palo Alto', 22); {code}
> - INSERT OVERWRITE DIRECTORY
> -- Syntax
> {code:java}
> INSERT OVERWRITE [ LOCAL ] DIRECTORY directory_path
> USING file_format [ OPTIONS ( key = val [ , ... ] ) ]
> { VALUES ( { value | NULL } [ , ... ] ) [ , ( ... ) ] | query }{code}
> -- Example
> {code:java}
> INSERT OVERWRITE DIRECTORY '/tmp/destination'
> USING parquet
> OPTIONS (col1=1, col2=2, col3='test')
> SELECT * FROM test_table;
> -- omit options
> INSERT OVERWRITE DIRECTORY '/tmp/destination'
> USING parquet
> SELECT * FROM test_table;{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6022) Support "CREATE TABLE ... LIKE" DDL
[
https://issues.apache.org/jira/browse/CALCITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770985#comment-17770985
]
Jiajun Xie commented on CALCITE-6022:
-
Should we add `server module` in Jira summary?
e.g. Support "CREATE TABLE ... LIKE" DDL in server module.
> Support "CREATE TABLE ... LIKE" DDL
> ---
>
> Key: CALCITE-6022
> URL: https://issues.apache.org/jira/browse/CALCITE-6022
> Project: Calcite
> Issue Type: New Feature
> Components: server
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> "CREATE TABLE ... LIKE" is SQL standard syntax, and some other dbms(mysql,
> postgresql, sparksql) support it. So I think it is worth implementing.
> Syntax:
> {code:sql}
> CREATE TABLE [IF NOT EXISTS] table_name
> LIKE source_table [ like_option ... ]{code}
> And for the `like_option`, I think the syntax of postgreSQL is more flexible
> and powerful, and I believe it is reasonable to be similar to postgreSQL. But
> there are not so many attributes in calcite, just keep GENERATED, DEFAULTS
> and ALL.
> {code:sql}
> { INCLUDING | EXCLUDING } { GENERATED | DEFAULTS | ALL }{code}
> Some related link:
> [https://www.postgresql.org/docs/current/sql-createtable.html]
> [https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#table%20definition]
> [https://dev.mysql.com/doc/refman/8.0/en/create-table-like.html]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6009) Add optimization to remove redundant Limit when its input's row number is less or equal to Limit's fetch
[
https://issues.apache.org/jira/browse/CALCITE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770829#comment-17770829
]
Jiajun Xie commented on CALCITE-6009:
-
The PR looks good to me.
Just a small suggestion:
`Add optimization to remove redundant LIMIT that is more than input row count`
maybe better.
> Add optimization to remove redundant Limit when its input's row number is
> less or equal to Limit's fetch
>
>
> Key: CALCITE-6009
> URL: https://issues.apache.org/jira/browse/CALCITE-6009
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> In calcite,Limit would be represented by Sort,such as `LogicalSort[fetch =
> 5]`.
> When the Limit' source row number is less than the Limit's fetch,we could
> remove the the redundant Limit.
> For example:
> {code:java}
> SELECT * FROM (VALUES 1,2,3,4,5,6) AS t1 LIMIT 10 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[10])
> LogicalProject(t1=[$0])
> LogicalValues(tuples=[[{ 1 }, { 2 }, { 3 }, { 4 }, { 5 }, { 6 }]]) {code}
> Because the Limit's source max row number is 6,the Limit's fetch is 10,so we
> could remove the redundant Limit.
> Another example is :
> {code:java}
> SELECT count(*) FROM orders LIMIT 2 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[2])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because Limit's source max row number is 1,the Limit's fetch is 2, so we
> could remove the redundant Limit.
> The logic is same as presto's RemoveRedundantLimit
> rule:https://github.com/prestodb/presto/blob/50fbc07111ecca60a1a5e62755f095fa204120d0/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantLimit.java#L27
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5570) Support nested map type for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5570.
-
Fix Version/s: 1.36.0
Resolution: Fixed
> Support nested map type for SqlDataTypeSpec
> ---
>
> Key: CALCITE-5570
> URL: https://issues.apache.org/jira/browse/CALCITE-5570
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There was added a similar support for arrays/multisets at
> https://issues.apache.org/jira/browse/CALCITE-3250
> however there is no support for maps so far.
> The issue is to add such support.
>
> I think I'd like to clarify is syntax for maps since it has 2 internal
> subtypes for keys and values may be something similar to ROW with delimiter
> like
> {code:sql}
> SELECT CAST(NULL AS MAP(INT, INT));
> -- or with square brackets similar to map constructor
> SELECT CAST(NULL AS MAP[INT, INT]);
> -- or with angle (Flink syntax)
> SELECT CAST(NULL AS MAP);
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5570) Support nested map type for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770817#comment-17770817
]
Jiajun Xie commented on CALCITE-5570:
-
Fixed in
[6f79436|https://github.com/apache/calcite/commit/6f79436c178beec639e559d9152c237bbf8ec3e8].
Thanks for your review [~Sergey Nuyanzin].
> Support nested map type for SqlDataTypeSpec
> ---
>
> Key: CALCITE-5570
> URL: https://issues.apache.org/jira/browse/CALCITE-5570
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There was added a similar support for arrays/multisets at
> https://issues.apache.org/jira/browse/CALCITE-3250
> however there is no support for maps so far.
> The issue is to add such support.
>
> I think I'd like to clarify is syntax for maps since it has 2 internal
> subtypes for keys and values may be something similar to ROW with delimiter
> like
> {code:sql}
> SELECT CAST(NULL AS MAP(INT, INT));
> -- or with square brackets similar to map constructor
> SELECT CAST(NULL AS MAP[INT, INT]);
> -- or with angle (Flink syntax)
> SELECT CAST(NULL AS MAP);
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5962) Support parse Spark-style syntax "LEFT ANTI JOIN" in Babel parser
[
https://issues.apache.org/jira/browse/CALCITE-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770006#comment-17770006
]
Jiajun Xie commented on CALCITE-5962:
-
Fixed in
[be21466|https://github.com/apache/calcite/commit/be2146679e3be0d4ce1a7578b93237c30b1a1709].
Thanks for your PR [~jiefei30] .
Thanks for your review [~hongyuguo], [~nobigo] , [~shenlang] , @linorosa.{*}{*}
> Support parse Spark-style syntax "LEFT ANTI JOIN" in Babel parser
> -
>
> Key: CALCITE-5962
> URL: https://issues.apache.org/jira/browse/CALCITE-5962
> Project: Calcite
> Issue Type: New Feature
> Components: babel
>Reporter: LiYuE
>Assignee: Mingcan Wang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Attachments: image-2023-08-28-19-47-40-712.png
>
>
> Currently, Spark SQL supports parsing the "anti join" SQL syntax [Spark anti
> join|https://spark.apache.org/docs/3.4.1/sql-ref-syntax-qry-select-join.html#anti-join],
> but the
> org.apache.calcite.sql.JoinType.java in Calcite does not include this
> enumeration. Therefore, it is hoped that Calcite can add an enumeration type
> for anti join to be compatible with the Spark syntax.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5962) Support parse Spark-style syntax "LEFT ANTI JOIN" in Babel parser
[ https://issues.apache.org/jira/browse/CALCITE-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie resolved CALCITE-5962. - Resolution: Fixed > Support parse Spark-style syntax "LEFT ANTI JOIN" in Babel parser > - > > Key: CALCITE-5962 > URL: https://issues.apache.org/jira/browse/CALCITE-5962 > Project: Calcite > Issue Type: New Feature > Components: babel >Reporter: LiYuE >Assignee: Mingcan Wang >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > Attachments: image-2023-08-28-19-47-40-712.png > > > Currently, Spark SQL supports parsing the "anti join" SQL syntax [Spark anti > join|https://spark.apache.org/docs/3.4.1/sql-ref-syntax-qry-select-join.html#anti-join], > but the > org.apache.calcite.sql.JoinType.java in Calcite does not include this > enumeration. Therefore, it is hoped that Calcite can add an enumeration type > for anti join to be compatible with the Spark syntax. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5940) Add the Rule to merge Limit
[
https://issues.apache.org/jira/browse/CALCITE-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769535#comment-17769535
]
Jiajun Xie commented on CALCITE-5940:
-
Fixed in
[aef9bdb|https://github.com/apache/calcite/commit/aef9bdb5c091e4df84eeb47a9aa70770dd3d3fb8].
Thanks for your PR [~shenlang].
Thanks for your review [~kgyrtkirk] , [~nobigo], [~taoran].
> Add the Rule to merge Limit
> ---
>
> Key: CALCITE-5940
> URL: https://issues.apache.org/jira/browse/CALCITE-5940
> Project: Calcite
> Issue Type: New Feature
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Now in calcite,the Limit will be represented using
> LogicalSort(fetch=[xx]),but there are few rules to optimize Limit.
> In trino and presto,there are many optimization rules to optimize Limit.
> For example,the sql:
> {code:java}
> select * from nation limit 0 {code}
> The limit 0 will use empty ValuesNode(Calcite LogicalValues) to optimize,so
> the SQL is not delivered to the Worker compute,the rule could see:
> [EvaluateZeroLimit|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/EvaluateZeroLimit.java#L28C1-L28C31]
> The sql:
> {code:java}
> select concat('-',N_REGIONKEY) from (select * from nation limit 1) limit
> 10 {code}
> It would be optimized by
> [MergeLimits|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/MergeLimits.java#L26]
> rule to:
> {code:java}
> select concat('-',N_REGIONKEY) from nation limit 10 {code}
> The value of limit takes the minimum of the outer limit and the inner limit.
> The sql:
> {code:java}
> select concat('-',N_REGIONKEY) from (SELECT * FROM nation order BY
> N_REGIONKEY DESC LIMIT 1) limit 10 {code}
> It would be optimized by
> [MergeLimitWithTopN|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/MergeLimitWithTopN.java#L28C1-L28C31]
> rule to:
> {code:java}
> SELECT concat('-',N_REGIONKEY) FROM nation order BY N_REGIONKEY DESC LIMIT
> 10{code}
> So I propose to add these three rules to Calcite as well, to optimize the
> Limit case.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5940) Add the Rule to merge Limit
[
https://issues.apache.org/jira/browse/CALCITE-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5940.
-
Resolution: Fixed
> Add the Rule to merge Limit
> ---
>
> Key: CALCITE-5940
> URL: https://issues.apache.org/jira/browse/CALCITE-5940
> Project: Calcite
> Issue Type: New Feature
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Now in calcite,the Limit will be represented using
> LogicalSort(fetch=[xx]),but there are few rules to optimize Limit.
> In trino and presto,there are many optimization rules to optimize Limit.
> For example,the sql:
> {code:java}
> select * from nation limit 0 {code}
> The limit 0 will use empty ValuesNode(Calcite LogicalValues) to optimize,so
> the SQL is not delivered to the Worker compute,the rule could see:
> [EvaluateZeroLimit|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/EvaluateZeroLimit.java#L28C1-L28C31]
> The sql:
> {code:java}
> select concat('-',N_REGIONKEY) from (select * from nation limit 1) limit
> 10 {code}
> It would be optimized by
> [MergeLimits|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/MergeLimits.java#L26]
> rule to:
> {code:java}
> select concat('-',N_REGIONKEY) from nation limit 10 {code}
> The value of limit takes the minimum of the outer limit and the inner limit.
> The sql:
> {code:java}
> select concat('-',N_REGIONKEY) from (SELECT * FROM nation order BY
> N_REGIONKEY DESC LIMIT 1) limit 10 {code}
> It would be optimized by
> [MergeLimitWithTopN|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/MergeLimitWithTopN.java#L28C1-L28C31]
> rule to:
> {code:java}
> SELECT concat('-',N_REGIONKEY) FROM nation order BY N_REGIONKEY DESC LIMIT
> 10{code}
> So I propose to add these three rules to Calcite as well, to optimize the
> Limit case.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5940) Add the Rule to optimize Limit
[
https://issues.apache.org/jira/browse/CALCITE-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769394#comment-17769394
]
Jiajun Xie commented on CALCITE-5940:
-
I will merge the PR, but I think that we can use a more accurate summary.
For example, `Add the Rule to merge Limit`.
[~shenlang] WDYT?
> Add the Rule to optimize Limit
> --
>
> Key: CALCITE-5940
> URL: https://issues.apache.org/jira/browse/CALCITE-5940
> Project: Calcite
> Issue Type: New Feature
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Now in calcite,the Limit will be represented using
> LogicalSort(fetch=[xx]),but there are few rules to optimize Limit.
> In trino and presto,there are many optimization rules to optimize Limit.
> For example,the sql:
> {code:java}
> select * from nation limit 0 {code}
> The limit 0 will use empty ValuesNode(Calcite LogicalValues) to optimize,so
> the SQL is not delivered to the Worker compute,the rule could see:
> [EvaluateZeroLimit|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/EvaluateZeroLimit.java#L28C1-L28C31]
> The sql:
> {code:java}
> select concat('-',N_REGIONKEY) from (select * from nation limit 1) limit
> 10 {code}
> It would be optimized by
> [MergeLimits|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/MergeLimits.java#L26]
> rule to:
> {code:java}
> select concat('-',N_REGIONKEY) from nation limit 10 {code}
> The value of limit takes the minimum of the outer limit and the inner limit.
> The sql:
> {code:java}
> select concat('-',N_REGIONKEY) from (SELECT * FROM nation order BY
> N_REGIONKEY DESC LIMIT 1) limit 10 {code}
> It would be optimized by
> [MergeLimitWithTopN|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/MergeLimitWithTopN.java#L28C1-L28C31]
> rule to:
> {code:java}
> SELECT concat('-',N_REGIONKEY) FROM nation order BY N_REGIONKEY DESC LIMIT
> 10{code}
> So I propose to add these three rules to Calcite as well, to optimize the
> Limit case.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5997) OFFSET operator is incorrectly unparsed
[
https://issues.apache.org/jira/browse/CALCITE-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5997.
-
Fix Version/s: 1.36.0
Assignee: Mihai Budiu
Resolution: Fixed
> OFFSET operator is incorrectly unparsed
> ---
>
> Key: CALCITE-5997
> URL: https://issues.apache.org/jira/browse/CALCITE-5997
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> The following query:
> {code:sql}
> select ARRAY[p2,p1,p0][OFFSET(2)] from (values (6, 4, 2)) as t(p0, p1, p2)
> {code}
> when parsed as a SqlNode and then unparsed produces:
> {code:sql}
> SELECT ARRAY["P2", "P1", "P0"][2]
> FROM (VALUES ROW(6, 4, 2)) AS "T" ("P0", "P1", "P2")
> {code}
> which no longer produces the same result (the OFFSET function call is
> missing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5997) OFFSET operator is incorrectly unparsed
[
https://issues.apache.org/jira/browse/CALCITE-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766961#comment-17766961
]
Jiajun Xie commented on CALCITE-5997:
-
Fixed in
[9ce7077|https://github.com/apache/calcite/commit/9ce7077bc8353e21e71ddb9f4a6a3025422ea8c4].
Thanks for the PR [~mbudiu] .
Thanks for the review [~tanclary] .
> OFFSET operator is incorrectly unparsed
> ---
>
> Key: CALCITE-5997
> URL: https://issues.apache.org/jira/browse/CALCITE-5997
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The following query:
> {code:sql}
> select ARRAY[p2,p1,p0][OFFSET(2)] from (values (6, 4, 2)) as t(p0, p1, p2)
> {code}
> when parsed as a SqlNode and then unparsed produces:
> {code:sql}
> SELECT ARRAY["P2", "P1", "P0"][2]
> FROM (VALUES ROW(6, 4, 2)) AS "T" ("P0", "P1", "P2")
> {code}
> which no longer produces the same result (the OFFSET function call is
> missing).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5999) DECIMAL literals are sometimes unparsed looking as DOUBLE literals
[ https://issues.apache.org/jira/browse/CALCITE-5999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766621#comment-17766621 ] Jiajun Xie commented on CALCITE-5999: - Fixed in [008c553|https://github.com/apache/calcite/commit/008c553aefacbe14787f50510c660a4dd739b54e]. Thanks for the PR [~mbudiu] . > DECIMAL literals are sometimes unparsed looking as DOUBLE literals > -- > > Key: CALCITE-5999 > URL: https://issues.apache.org/jira/browse/CALCITE-5999 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > Consider a DECIMAL literal such as "0.1" > When unparsed this will show up as 1E-17, which is interpreted by SQL as a > double literal. > The bug is in the function SqlNumericLiteral.toValue(). The function calls > toString() on a BigDecimal value, but it should probably call toPlainString() > instead. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5999) DECIMAL literals are sometimes unparsed looking as DOUBLE literals
[ https://issues.apache.org/jira/browse/CALCITE-5999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie resolved CALCITE-5999. - Fix Version/s: 1.36.0 Assignee: Mihai Budiu Resolution: Fixed > DECIMAL literals are sometimes unparsed looking as DOUBLE literals > -- > > Key: CALCITE-5999 > URL: https://issues.apache.org/jira/browse/CALCITE-5999 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > Consider a DECIMAL literal such as "0.1" > When unparsed this will show up as 1E-17, which is interpreted by SQL as a > double literal. > The bug is in the function SqlNumericLiteral.toValue(). The function calls > toString() on a BigDecimal value, but it should probably call toPlainString() > instead. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5523) RelToSql converter generates GROUP BY clause with window expression
[
https://issues.apache.org/jira/browse/CALCITE-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766053#comment-17766053
]
Jiajun Xie edited comment on CALCITE-5523 at 9/17/23 8:14 AM:
--
[~lchistov1987] , Oracle support it.
{code:java}
// Oracle does support nested aggregations
final String expectedOracle =
"SELECT COUNT(DISTINCT RANK() OVER (ORDER BY \"SAL\")) \"c\"\n"
+ "FROM \"scott\".\"EMP\"\n"
+ "HAVING COUNT(DISTINCT RANK() OVER (ORDER BY \"SAL\")) >= 10";
relFn(relFn).withOracle().ok(expectedOracle); {code}
So I use `supportsNestedAggregations()` .
was (Author: jiajunbernoulli):
[~lchistov1987] , Oracle support it.
{code:java}
// Oracle does support nested aggregations
final String expectedOracle =
"SELECT COUNT(DISTINCT RANK() OVER (ORDER BY \"SAL\")) \"c\"\n"
+ "FROM \"scott\".\"EMP\"\n"
+ "HAVING COUNT(DISTINCT RANK() OVER (ORDER BY \"SAL\")) >= 10";
relFn(relFn).withOracle().ok(expectedOracle); {code}
So I use `supportsNestedAggregations()` .
> RelToSql converter generates GROUP BY clause with window expression
> ---
>
> Key: CALCITE-5523
> URL: https://issues.apache.org/jira/browse/CALCITE-5523
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Leonid Chistov
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
>
> Wrong SQL code is generated when aggregation is done on the field being a
> result of window expression evaluation.
> Example can be demonstrated by adding following code to
> RelToSqlConverterTest.java:
> {code:java}
> @Test void testConvertWindowGroupByToSql() {
> String query = "SELECT * FROM ("
> + "SELECT rank() over (order by \"hire_date\") \"rank\" FROM
> \"employee\""
> + ") GROUP BY \"rank\"";
> String expected ="SELECT * FROM ("
> + "SELECT rank() over (order by \"hire_date\") AS \"$0\" FROM
> \"employee\""
> + ") GROUP BY \"$0\"";
> sql(query).ok(expected);
> }
> {code}
> Generated SQL code will look like:
> {code:java}
> SELECT RANK() OVER (ORDER BY hire_date) AS rank
> FROM foodmart.employee
> GROUP BY RANK() OVER (ORDER BY hire_date){code}
> This is incorrect - window expressions are not allowed in GROUP BY clause by
> SQL standard and Calcite itself would produce following error message if this
> SQL code would be passed as input:
> {code:java}
> Windowed aggregate expression is illegal in GROUP BY clause {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5523) RelToSql converter generates GROUP BY clause with window expression
[
https://issues.apache.org/jira/browse/CALCITE-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766053#comment-17766053
]
Jiajun Xie commented on CALCITE-5523:
-
[~lchistov1987] , Oracle support it.
{code:java}
// Oracle does support nested aggregations
final String expectedOracle =
"SELECT COUNT(DISTINCT RANK() OVER (ORDER BY \"SAL\")) \"c\"\n"
+ "FROM \"scott\".\"EMP\"\n"
+ "HAVING COUNT(DISTINCT RANK() OVER (ORDER BY \"SAL\")) >= 10";
relFn(relFn).withOracle().ok(expectedOracle); {code}
So I use `supportsNestedAggregations()` .
> RelToSql converter generates GROUP BY clause with window expression
> ---
>
> Key: CALCITE-5523
> URL: https://issues.apache.org/jira/browse/CALCITE-5523
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Leonid Chistov
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
>
> Wrong SQL code is generated when aggregation is done on the field being a
> result of window expression evaluation.
> Example can be demonstrated by adding following code to
> RelToSqlConverterTest.java:
> {code:java}
> @Test void testConvertWindowGroupByToSql() {
> String query = "SELECT * FROM ("
> + "SELECT rank() over (order by \"hire_date\") \"rank\" FROM
> \"employee\""
> + ") GROUP BY \"rank\"";
> String expected ="SELECT * FROM ("
> + "SELECT rank() over (order by \"hire_date\") AS \"$0\" FROM
> \"employee\""
> + ") GROUP BY \"$0\"";
> sql(query).ok(expected);
> }
> {code}
> Generated SQL code will look like:
> {code:java}
> SELECT RANK() OVER (ORDER BY hire_date) AS rank
> FROM foodmart.employee
> GROUP BY RANK() OVER (ORDER BY hire_date){code}
> This is incorrect - window expressions are not allowed in GROUP BY clause by
> SQL standard and Calcite itself would produce following error message if this
> SQL code would be passed as input:
> {code:java}
> Windowed aggregate expression is illegal in GROUP BY clause {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6007) Sqlwith as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765921#comment-17765921
]
Jiajun Xie edited comment on CALCITE-6007 at 9/16/23 7:51 AM:
--
[~wenruimeng] , Maybe `CTE` or `With clause` will be better than `SqlWith`.
We prefer vocabulary that users can understand in Jira summary.
`SqlWith` is a SqlNode that is only known to developers.
was (Author: jiajunbernoulli):
[~wenruimeng] , Maybe `CTE` or `With clause` will be better than `SqlWith`.
We prefer vocabulary that users can understand.
`SqlWith` is a SqlNode that is only known to developers.
> Sqlwith as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6007) Sqlwith as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765921#comment-17765921
]
Jiajun Xie commented on CALCITE-6007:
-
[~wenruimeng] , Maybe `CTE` or `With clause` will be better than `SqlWith`.
We prefer vocabulary that users can understand.
`SqlWith` is a SqlNode that is only known to developers.
> Sqlwith as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6007) Sqlwith as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765921#comment-17765921
]
Jiajun Xie edited comment on CALCITE-6007 at 9/16/23 7:50 AM:
--
[~wenruimeng] , Maybe `CTE` or `With clause` will be better than `SqlWith`.
We prefer vocabulary that users can understand.
`SqlWith` is a SqlNode that is only known to developers.
was (Author: jiajunbernoulli):
[~wenruimeng] , Maybe `CTE` or `With clause` will be better than `SqlWith`.
We prefer vocabulary that users can understand.
`SqlWith` is a SqlNode that is only known to developers.
> Sqlwith as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5570) Support nested map type for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765897#comment-17765897
]
Jiajun Xie commented on CALCITE-5570:
-
[~Sergey Nuyanzin] , Do you have any suggestions? I plan to merge it next week.
https://github.com/apache/calcite/pull/3105/files#diff-766dbf236baaf33399a8d3620404b261faa80c27dadb95379e0747f915380e44
> Support nested map type for SqlDataTypeSpec
> ---
>
> Key: CALCITE-5570
> URL: https://issues.apache.org/jira/browse/CALCITE-5570
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There was added a similar support for arrays/multisets at
> https://issues.apache.org/jira/browse/CALCITE-3250
> however there is no support for maps so far.
> The issue is to add such support.
>
> I think I'd like to clarify is syntax for maps since it has 2 internal
> subtypes for keys and values may be something similar to ROW with delimiter
> like
> {code:sql}
> SELECT CAST(NULL AS MAP(INT, INT));
> -- or with square brackets similar to map constructor
> SELECT CAST(NULL AS MAP[INT, INT]);
> -- or with angle (Flink syntax)
> SELECT CAST(NULL AS MAP);
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5836) Implement Rel2Sql for MERGE
[ https://issues.apache.org/jira/browse/CALCITE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie resolved CALCITE-5836. - Fix Version/s: 1.36.0 Resolution: Fixed > Implement Rel2Sql for MERGE > --- > > Key: CALCITE-5836 > URL: https://issues.apache.org/jira/browse/CALCITE-5836 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Gregory Hart >Assignee: Gregory Hart >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > Attachments: image-2023-08-28-10-28-57-584.png > > > Add support for MERGE operations in RelToSqlConverter.visit(TableModify). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5836) Implement Rel2Sql for MERGE
[ https://issues.apache.org/jira/browse/CALCITE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765417#comment-17765417 ] Jiajun Xie commented on CALCITE-5836: - Fixed in [f3f5e7e|https://github.com/apache/calcite/commit/f3f5e7eeacea2216123f9e9c3094a0926096b923], Thanks PR for [~freastro] and [~hongyuguo] . > Implement Rel2Sql for MERGE > --- > > Key: CALCITE-5836 > URL: https://issues.apache.org/jira/browse/CALCITE-5836 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Gregory Hart >Assignee: Gregory Hart >Priority: Major > Labels: pull-request-available > Attachments: image-2023-08-28-10-28-57-584.png > > > Add support for MERGE operations in RelToSqlConverter.visit(TableModify). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5985) FilterTableFunctionTransposeRule should not use "Logical" RelNodes
[
https://issues.apache.org/jira/browse/CALCITE-5985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763397#comment-17763397
]
Jiajun Xie edited comment on CALCITE-5985 at 9/10/23 7:12 AM:
--
I can't find any unit test for FilterTableFunctionTransposeRule.
And I write a unit test to match it.
{code:java}
@Test void testFilterTableFunctionScanTranspose() {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(CoreRules.FILTER_TABLE_FUNCTION_TRANSPOSE)
.build();
final String sql = "select * from table(dedup(cursor(select ename from emp),
cursor(select name from dept), 'NAME')) where name = ''";
sql(sql)
.withProgram(program).check();
} {code}
Th planBefore is
{code:java}
LogicalProject(NAME=[$0])
LogicalFilter(condition=[=($0, '')])
LogicalTableFunctionScan(invocation=[DEDUP(CAST($0):CURSOR NOT NULL,
CAST($1):CURSOR NOT NULL, 'NAME')], rowType=[RecordType(VARCHAR(1024) NAME)])
LogicalProject(ENAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalProject(NAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
But FilterTableFunctionTransposeRule will return.
{code:java}
Set columnMappings = funcRel.getColumnMappings();
if (columnMappings == null || columnMappings.isEmpty()) {
// No column mapping information, so no push-down
// possible.
return;
}{code}
[~scarlin] , Do you have any unit test?
was (Author: jiajunbernoulli):
I can't find any unit tests for FilterTableFunctionTransposeRule.
And I write a unit test to match it.
{code:java}
@Test void testFilterTableFunctionScanTranspose() {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(CoreRules.FILTER_TABLE_FUNCTION_TRANSPOSE)
.build();
final String sql = "select * from table(dedup(cursor(select ename from emp),
cursor(select name from dept), 'NAME')) where name = ''";
sql(sql)
.withProgram(program).check();
} {code}
Th planBefore is
{code:java}
LogicalProject(NAME=[$0])
LogicalFilter(condition=[=($0, '')])
LogicalTableFunctionScan(invocation=[DEDUP(CAST($0):CURSOR NOT NULL,
CAST($1):CURSOR NOT NULL, 'NAME')], rowType=[RecordType(VARCHAR(1024) NAME)])
LogicalProject(ENAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalProject(NAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
But FilterTableFunctionTransposeRule will return.
{code:java}
Set columnMappings = funcRel.getColumnMappings();
if (columnMappings == null || columnMappings.isEmpty()) {
// No column mapping information, so no push-down
// possible.
return;
}{code}
[~scarlin] , Do you have any unit tests?
> FilterTableFunctionTransposeRule should not use "Logical" RelNodes
> --
>
> Key: CALCITE-5985
> URL: https://issues.apache.org/jira/browse/CALCITE-5985
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Steve Carlin
>Priority: Major
>
> The FilterTableFunctionTransposeRule uses LogicalTableFunctionScan and
> LogicalFilter RelNodes in its rule. We should be using the appropriate
> TableFunctionScan and Filter interface RelNodes instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5985) FilterTableFunctionTransposeRule should not use "Logical" RelNodes
[
https://issues.apache.org/jira/browse/CALCITE-5985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763397#comment-17763397
]
Jiajun Xie edited comment on CALCITE-5985 at 9/10/23 7:10 AM:
--
I can't find any unit tests for FilterTableFunctionTransposeRule.
And I write a unit test to match it.
{code:java}
@Test void testFilterTableFunctionScanTranspose() {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(CoreRules.FILTER_TABLE_FUNCTION_TRANSPOSE)
.build();
final String sql = "select * from table(dedup(cursor(select ename from emp),
cursor(select name from dept), 'NAME')) where name = ''";
sql(sql)
.withProgram(program).check();
} {code}
Th planBefore is
{code:java}
LogicalProject(NAME=[$0])
LogicalFilter(condition=[=($0, '')])
LogicalTableFunctionScan(invocation=[DEDUP(CAST($0):CURSOR NOT NULL,
CAST($1):CURSOR NOT NULL, 'NAME')], rowType=[RecordType(VARCHAR(1024) NAME)])
LogicalProject(ENAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalProject(NAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
But FilterTableFunctionTransposeRule will return.
{code:java}
Set columnMappings = funcRel.getColumnMappings();
if (columnMappings == null || columnMappings.isEmpty()) {
// No column mapping information, so no push-down
// possible.
return;
}{code}
[~scarlin] , Do you have any unit tests?
was (Author: jiajunbernoulli):
I can't find any unit tests for FilterTableFunctionTransposeRule.
And I write a unit test to match it.
{code:java}
@Test void testFilterTableFunctionScanTranspose() {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(CoreRules.FILTER_TABLE_FUNCTION_TRANSPOSE)
.build();
final String sql = "select * from table(dedup(cursor(select ename from emp),
cursor(select name from dept), 'NAME')) where name = ''";
sql(sql)
.withProgram(program).check();
} {code}
Th planBefore is
{code:java}
LogicalProject(NAME=[$0])
LogicalFilter(condition=[=($0, '')])
LogicalTableFunctionScan(invocation=[DEDUP(CAST($0):CURSOR NOT NULL,
CAST($1):CURSOR NOT NULL, 'NAME')], rowType=[RecordType(VARCHAR(1024) NAME)])
LogicalProject(ENAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalProject(NAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
But FilterTableFunctionTransposeRule will return.
{code:java}
Set columnMappings = funcRel.getColumnMappings();
if (columnMappings == null || columnMappings.isEmpty()) {
// No column mapping information, so no push-down
// possible.
return;
}{code}
[~scarlin] , Do you have any unit tests?
> FilterTableFunctionTransposeRule should not use "Logical" RelNodes
> --
>
> Key: CALCITE-5985
> URL: https://issues.apache.org/jira/browse/CALCITE-5985
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Steve Carlin
>Priority: Major
>
> The FilterTableFunctionTransposeRule uses LogicalTableFunctionScan and
> LogicalFilter RelNodes in its rule. We should be using the appropriate
> TableFunctionScan and Filter interface RelNodes instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5985) FilterTableFunctionTransposeRule should not use "Logical" RelNodes
[
https://issues.apache.org/jira/browse/CALCITE-5985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763397#comment-17763397
]
Jiajun Xie commented on CALCITE-5985:
-
I can't find any unit tests for FilterTableFunctionTransposeRule.
And I write a unit test to match it.
{code:java}
@Test void testFilterTableFunctionScanTranspose() {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(CoreRules.FILTER_TABLE_FUNCTION_TRANSPOSE)
.build();
final String sql = "select * from table(dedup(cursor(select ename from emp),
cursor(select name from dept), 'NAME')) where name = ''";
sql(sql)
.withProgram(program).check();
} {code}
Th planBefore is
{code:java}
LogicalProject(NAME=[$0])
LogicalFilter(condition=[=($0, '')])
LogicalTableFunctionScan(invocation=[DEDUP(CAST($0):CURSOR NOT NULL,
CAST($1):CURSOR NOT NULL, 'NAME')], rowType=[RecordType(VARCHAR(1024) NAME)])
LogicalProject(ENAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalProject(NAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
But FilterTableFunctionTransposeRule will return.
{code:java}
Set columnMappings = funcRel.getColumnMappings();
if (columnMappings == null || columnMappings.isEmpty()) {
// No column mapping information, so no push-down
// possible.
return;
}{code}
[~scarlin] , Do you have any unit tests?
> FilterTableFunctionTransposeRule should not use "Logical" RelNodes
> --
>
> Key: CALCITE-5985
> URL: https://issues.apache.org/jira/browse/CALCITE-5985
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Steve Carlin
>Priority: Major
>
> The FilterTableFunctionTransposeRule uses LogicalTableFunctionScan and
> LogicalFilter RelNodes in its rule. We should be using the appropriate
> TableFunctionScan and Filter interface RelNodes instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5931) Allow integers like 1.00 in window frame
[ https://issues.apache.org/jira/browse/CALCITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie resolved CALCITE-5931. - Resolution: Fixed > Allow integers like 1.00 in window frame > > > Key: CALCITE-5931 > URL: https://issues.apache.org/jira/browse/CALCITE-5931 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Claude Brisson >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > When a number of rows is specified for a window, the code checks that the > provided literal is an integral number. > But the provided check leaves aside numbers like "1.00" (with a scale of 2, > but with trailing zeros). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5931) Allow integers like 1.00 in window frame
[ https://issues.apache.org/jira/browse/CALCITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763395#comment-17763395 ] Jiajun Xie commented on CALCITE-5931: - Fixed in [d4046d0|https://github.com/apache/calcite/commit/d4046d027450bb792481fae46af76719d562c904] Thanks PR for [~cbrisson] , thanks review for [~julianhyde]. > Allow integers like 1.00 in window frame > > > Key: CALCITE-5931 > URL: https://issues.apache.org/jira/browse/CALCITE-5931 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Claude Brisson >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > When a number of rows is specified for a window, the code checks that the > provided literal is an integral number. > But the provided check leaves aside numbers like "1.00" (with a scale of 2, > but with trailing zeros). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5931) Allow integers like 1.00 in window frame
[ https://issues.apache.org/jira/browse/CALCITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763309#comment-17763309 ] Jiajun Xie commented on CALCITE-5931: - [~cbrisson] , Your PR is already dirty because force-pushed main. I cherry-pick your commit and add test in `winagg.iq`, welcome to review. [https://github.com/apache/calcite/pull/3413] Let's merge it before the release of version 1.36. > Allow integers like 1.00 in window frame > > > Key: CALCITE-5931 > URL: https://issues.apache.org/jira/browse/CALCITE-5931 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Claude Brisson >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > When a number of rows is specified for a window, the code checks that the > provided literal is an integral number. > But the provided check leaves aside numbers like "1.00" (with a scale of 2, > but with trailing zeros). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762924#comment-17762924
]
Jiajun Xie commented on CALCITE-5944:
-
Fixed in
[64268b9|https://github.com/apache/calcite/commit/64268b9dd70bcdc15a3421ab120b8e5ecba17339].
Thanks for your review [~julianhyde] , [~rubenql], [~shenlang].{*}{*}
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Some metadata need to be implemented.
> * RelMdAllPredicates
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdMaxRowCount
> * RelMdMinRowCount
> * RelMdPredicates
> * RelMdRowCount
> Some metadata have been implemented.
> * RelMdTableReferences
> * RelMdNodeTypes
> Some metadabata not need to be implemented.
> * RelMdColumnUniqueness (Handle SingleRel)
> * RelMdDistribution (Handle SingleRel)
> * RelMdDistinctRowCount（Handle RelNode）
> * RelMdExplainVisibility（Only TableScan）
> * RelMdLowerBoundCost（Handle RelNode）
> * RelMdMemory（Handle RelNode）
> * RelMdParallelism（Handle RelNode）
> * RelMdPercentageOriginalRows（Handle RelNode）
> * RelMdPopulationSize（Handle RelNode）
> * RelMdSelectivity（Must have predicate）
> * RelMdSize（Handle RelNode）
> * RelMdUniqueKeys（Handle SingleRel）
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5944.
-
Fix Version/s: 1.36.0
Resolution: Fixed
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Some metadata need to be implemented.
> * RelMdAllPredicates
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdMaxRowCount
> * RelMdMinRowCount
> * RelMdPredicates
> * RelMdRowCount
> Some metadata have been implemented.
> * RelMdTableReferences
> * RelMdNodeTypes
> Some metadabata not need to be implemented.
> * RelMdColumnUniqueness (Handle SingleRel)
> * RelMdDistribution (Handle SingleRel)
> * RelMdDistinctRowCount（Handle RelNode）
> * RelMdExplainVisibility（Only TableScan）
> * RelMdLowerBoundCost（Handle RelNode）
> * RelMdMemory（Handle RelNode）
> * RelMdParallelism（Handle RelNode）
> * RelMdPercentageOriginalRows（Handle RelNode）
> * RelMdPopulationSize（Handle RelNode）
> * RelMdSelectivity（Must have predicate）
> * RelMdSize（Handle RelNode）
> * RelMdUniqueKeys（Handle SingleRel）
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5931) Allow integers like 1.00 in window frame
[ https://issues.apache.org/jira/browse/CALCITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760668#comment-17760668 ] Jiajun Xie commented on CALCITE-5931: - [~cbrisson] , You can add a test to `winagg.iq`. e.g. [https://github.com/apache/calcite/pull/2981/files#diff-127661cfd09664ac3aecf2105284a6ca0543f6ff4158e215e6ffc9a61cd60294] If you encounter difficulties, please leave a message for discussion. > Allow integers like 1.00 in window frame > > > Key: CALCITE-5931 > URL: https://issues.apache.org/jira/browse/CALCITE-5931 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Claude Brisson >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > When a number of rows is specified for a window, the code checks that the > provided literal is an integral number. > But the provided check leaves aside numbers like "1.00" (with a scale of 2, > but with trailing zeros). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5836) Implement Rel2Sql for MERGE
[ https://issues.apache.org/jira/browse/CALCITE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759415#comment-17759415 ] Jiajun Xie commented on CALCITE-5836: - [~hongyuguo] , you can refer to https://github.com/apache/calcite/pull/2724 !image-2023-08-28-10-28-57-584.png! > Implement Rel2Sql for MERGE > --- > > Key: CALCITE-5836 > URL: https://issues.apache.org/jira/browse/CALCITE-5836 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Gregory Hart >Assignee: Gregory Hart >Priority: Major > Labels: pull-request-available > Attachments: image-2023-08-28-10-28-57-584.png > > > Add support for MERGE operations in RelToSqlConverter.visit(TableModify). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5836) Implement Rel2Sql for MERGE
[ https://issues.apache.org/jira/browse/CALCITE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie updated CALCITE-5836: Attachment: image-2023-08-28-10-28-57-584.png > Implement Rel2Sql for MERGE > --- > > Key: CALCITE-5836 > URL: https://issues.apache.org/jira/browse/CALCITE-5836 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Gregory Hart >Assignee: Gregory Hart >Priority: Major > Labels: pull-request-available > Attachments: image-2023-08-28-10-28-57-584.png > > > Add support for MERGE operations in RelToSqlConverter.visit(TableModify). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5836) Implement Rel2Sql for MERGE
[
https://issues.apache.org/jira/browse/CALCITE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759412#comment-17759412
]
Jiajun Xie commented on CALCITE-5836:
-
[~hongyuguo] , I noticed that you used a lot of his code.
Can you add [~freastro] as a co author?
{code:java}
Co-authored-by: user_name{code}
> Implement Rel2Sql for MERGE
> ---
>
> Key: CALCITE-5836
> URL: https://issues.apache.org/jira/browse/CALCITE-5836
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Gregory Hart
>Assignee: Gregory Hart
>Priority: Major
> Labels: pull-request-available
>
> Add support for MERGE operations in RelToSqlConverter.visit(TableModify).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759235#comment-17759235
]
Jiajun Xie edited comment on CALCITE-5944 at 8/26/23 10:34 AM:
---
Would anyone please review it?
https://github.com/apache/calcite/pull/3382
was (Author: jiajunbernoulli):
Would anyone please review it?
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Some metadata need to be implemented.
> * RelMdAllPredicates
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdMaxRowCount
> * RelMdMinRowCount
> * RelMdPredicates
> * RelMdRowCount
> Some metadata have been implemented.
> * RelMdTableReferences
> * RelMdNodeTypes
> Some metadabata not need to be implemented.
> * RelMdColumnUniqueness (Handle SingleRel)
> * RelMdDistribution (Handle SingleRel)
> * RelMdDistinctRowCount（Handle RelNode）
> * RelMdExplainVisibility（Only TableScan）
> * RelMdLowerBoundCost（Handle RelNode）
> * RelMdMemory（Handle RelNode）
> * RelMdParallelism（Handle RelNode）
> * RelMdPercentageOriginalRows（Handle RelNode）
> * RelMdPopulationSize（Handle RelNode）
> * RelMdSelectivity（Must have predicate）
> * RelMdSize（Handle RelNode）
> * RelMdUniqueKeys（Handle SingleRel）
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759235#comment-17759235
]
Jiajun Xie commented on CALCITE-5944:
-
Would anyone please review it?
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Some metadata need to be implemented.
> * RelMdAllPredicates
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdMaxRowCount
> * RelMdMinRowCount
> * RelMdPredicates
> * RelMdRowCount
> Some metadata have been implemented.
> * RelMdTableReferences
> * RelMdNodeTypes
> Some metadabata not need to be implemented.
> * RelMdColumnUniqueness (Handle SingleRel)
> * RelMdDistribution (Handle SingleRel)
> * RelMdDistinctRowCount（Handle RelNode）
> * RelMdExplainVisibility（Only TableScan）
> * RelMdLowerBoundCost（Handle RelNode）
> * RelMdMemory（Handle RelNode）
> * RelMdParallelism（Handle RelNode）
> * RelMdPercentageOriginalRows（Handle RelNode）
> * RelMdPopulationSize（Handle RelNode）
> * RelMdSelectivity（Must have predicate）
> * RelMdSize（Handle RelNode）
> * RelMdUniqueKeys（Handle SingleRel）
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5956) Support parsing non-standard collection types
[
https://issues.apache.org/jira/browse/CALCITE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759231#comment-17759231
]
Jiajun Xie commented on CALCITE-5956:
-
IMO: The core module supports too many parsing methods, which can easily lead
to confusion.
Map has two parameters, which are quite special. So we need `Map` in core
module.
{{But `ARRAY`}} and `{{{}MULITSET` are not necessary.{}}}
I suggest supporting it in the babel module
> Support parsing non-standard collection types
> -
>
> Key: CALCITE-5956
> URL: https://issues.apache.org/jira/browse/CALCITE-5956
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> Calcite support SQL standard collection types. For example:
> {code:sql}
> INTEGER ARRAY;
> INTEGER ARRAY ARRAY;
> VARCHAR(5) MULTISET;
> INTEGER MULTISET ARRAY;{code}
> Many DBMS support a dialect of {{ARRAY}} and {{MULITSET}},
> I think Calcite can also support this dialect in core Parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5922) The SQL generated for the POSITION function(with 3 input arguments) by the SparkSqlDialect is not recognized by Spark SQL
[
https://issues.apache.org/jira/browse/CALCITE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759009#comment-17759009
]
Jiajun Xie commented on CALCITE-5922:
-
Fixed in
[730361b|https://github.com/apache/calcite/commit/730361b66442e5d12448e120e8ce67fc070b271a].
[~hongyuguo] , Thanks for you PR.
[~nobigo] , Thanks for your review.
> The SQL generated for the POSITION function(with 3 input arguments) by the
> SparkSqlDialect is not recognized by Spark SQL
> -
>
> Key: CALCITE-5922
> URL: https://issues.apache.org/jira/browse/CALCITE-5922
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> In SparkSQL, POSITION(substr, str[, pos]) function only accept
> comma-separated when there are 3 arguments.
> For example:
> {code:java}
> // SparkSQL accepted SQL
> select POSITION('a', 'abc', 1);{code}
> Calcite will use the IN and FROM keyword to separate the input arguments when
> unparsing.
> {code:java}
> // Calcite accepted and unparsed SQL
> select POSITION('a' IN 'abc' FROM 1){code}
> For 2 augument inputs, SparkSQL accept both syntaxes. So I think we should
> write a rule in SparkSqlDialect to convert keyword-separated syntax to
> comma-separted syntax for POSITION function.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5922) The SQL generated for the POSITION function(with 3 input arguments) by the SparkSqlDialect is not recognized by Spark SQL
[
https://issues.apache.org/jira/browse/CALCITE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5922.
-
Resolution: Fixed
> The SQL generated for the POSITION function(with 3 input arguments) by the
> SparkSqlDialect is not recognized by Spark SQL
> -
>
> Key: CALCITE-5922
> URL: https://issues.apache.org/jira/browse/CALCITE-5922
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> In SparkSQL, POSITION(substr, str[, pos]) function only accept
> comma-separated when there are 3 arguments.
> For example:
> {code:java}
> // SparkSQL accepted SQL
> select POSITION('a', 'abc', 1);{code}
> Calcite will use the IN and FROM keyword to separate the input arguments when
> unparsing.
> {code:java}
> // Calcite accepted and unparsed SQL
> select POSITION('a' IN 'abc' FROM 1){code}
> For 2 augument inputs, SparkSQL accept both syntaxes. So I think we should
> write a rule in SparkSqlDialect to convert keyword-separated syntax to
> comma-separted syntax for POSITION function.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5954) Support MERGE in RelToSqlConverter
[ https://issues.apache.org/jira/browse/CALCITE-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758836#comment-17758836 ] Jiajun Xie commented on CALCITE-5954: - [~hongyuguo] ，Thanks for you create JIRA. I mark it as duplicated, because CALCITE-5836 is IN PROGRESS. > Support MERGE in RelToSqlConverter > --- > > Key: CALCITE-5954 > URL: https://issues.apache.org/jira/browse/CALCITE-5954 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.35.0 >Reporter: hongyu guo >Assignee: hongyu guo >Priority: Major > > We have implemented validation for the *MERGE INTO* clause, but Calcite does > not support converting TableModify to SqlMerge. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5954) Support MERGE in RelToSqlConverter
[ https://issues.apache.org/jira/browse/CALCITE-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie resolved CALCITE-5954. - Fix Version/s: (was: 1.36.0) Resolution: Duplicate > Support MERGE in RelToSqlConverter > --- > > Key: CALCITE-5954 > URL: https://issues.apache.org/jira/browse/CALCITE-5954 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.35.0 >Reporter: hongyu guo >Assignee: hongyu guo >Priority: Major > > We have implemented validation for the *MERGE INTO* clause, but Calcite does > not support converting TableModify to SqlMerge. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-5944:
Description:
For the sql
{code:java}
select * from emp tablesample system(20) {code}
`mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
Some metadata need to be implemented.
* RelMdAllPredicates
* RelMdColumnOrigins
* RelMdExpressionLineage
* RelMdMaxRowCount
* RelMdMinRowCount
* RelMdPredicates
* RelMdRowCount
Some metadata have been implemented.
* RelMdTableReferences
* RelMdNodeTypes
Some metadabata not need to be implemented.
* RelMdColumnUniqueness (Handle SingleRel)
* RelMdDistribution (Handle SingleRel)
* RelMdDistinctRowCount（Handle RelNode）
* RelMdExplainVisibility（Only TableScan）
* RelMdLowerBoundCost（Handle RelNode）
* RelMdMemory（Handle RelNode）
* RelMdParallelism（Handle RelNode）
* RelMdPercentageOriginalRows（Handle RelNode）
* RelMdPopulationSize（Handle RelNode）
* RelMdSelectivity（Must have predicate）
* RelMdSize（Handle RelNode）
* RelMdUniqueKeys（Handle SingleRel）
was:
For the sql
{code:java}
select * from emp tablesample system(20) {code}
`mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
Other metadata also need to be implemented.
* RelMdColumnOrigins
* RelMdExpressionLineage
* RelMdPredicates
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Some metadata need to be implemented.
> * RelMdAllPredicates
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdMaxRowCount
> * RelMdMinRowCount
> * RelMdPredicates
> * RelMdRowCount
> Some metadata have been implemented.
> * RelMdTableReferences
> * RelMdNodeTypes
> Some metadabata not need to be implemented.
> * RelMdColumnUniqueness (Handle SingleRel)
> * RelMdDistribution (Handle SingleRel)
> * RelMdDistinctRowCount（Handle RelNode）
> * RelMdExplainVisibility（Only TableScan）
> * RelMdLowerBoundCost（Handle RelNode）
> * RelMdMemory（Handle RelNode）
> * RelMdParallelism（Handle RelNode）
> * RelMdPercentageOriginalRows（Handle RelNode）
> * RelMdPopulationSize（Handle RelNode）
> * RelMdSelectivity（Must have predicate）
> * RelMdSize（Handle RelNode）
> * RelMdUniqueKeys（Handle SingleRel）
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757171#comment-17757171
]
Jiajun Xie commented on CALCITE-5944:
-
Initially, I planned to discuss separately, so I create different Jira ticket.
But now the Jira include https://issues.apache.org/jira/browse/CALCITE-5943, so
I closed it.
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Other metadata also need to to implemented.
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdPredicates
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-5944:
Description:
For the sql
{code:java}
select * from emp tablesample system(20) {code}
`mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
Other metadata also need to be implemented.
* RelMdColumnOrigins
* RelMdExpressionLineage
* RelMdPredicates
was:
For the sql
{code:java}
select * from emp tablesample system(20) {code}
`mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
Other metadata also need to to implemented.
* RelMdColumnOrigins
* RelMdExpressionLineage
* RelMdPredicates
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Other metadata also need to be implemented.
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdPredicates
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CALCITE-5943) RelMdSelectivity can return more precise selectivity for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie closed CALCITE-5943.
---
Resolution: Duplicate
> RelMdSelectivity can return more precise selectivity for Sample
> ---
>
> Key: CALCITE-5943
> URL: https://issues.apache.org/jira/browse/CALCITE-5943
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
>
> For the SQL
> {code:java}
> select * from emp tablesample bernoulli(50) {code}
> selectivity is 1.0, maybe 0.5 will be better.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-5944:
Description:
For the sql
{code:java}
select * from emp tablesample system(20) {code}
`mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
Other metadata also need to to implemented.
* RelMdColumnOrigins
* RelMdExpressionLineage
* RelMdPredicates
was:
For the sql
{code:java}
select * from emp tablesample system(20) {code}
`mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
Summary: Add metadata for Sample (was: RelMdRowCount can return more
accurate rowCount for Sample)
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Other metadata also need to to implemented.
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdPredicates
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5943) RelMdSelectivity can return more precise selectivity for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756686#comment-17756686
]
Jiajun Xie commented on CALCITE-5943:
-
[~libenchao] No, this is discussion about `Selectivity`.
I can't found anything about `Selectivity` in ANSI SQL 2011.
Here is concept in Oracle:
https://docs.oracle.com/cd/B10500_01/appdev.920/a96595/dci08opt.htm
> RelMdSelectivity can return more precise selectivity for Sample
> ---
>
> Key: CALCITE-5943
> URL: https://issues.apache.org/jira/browse/CALCITE-5943
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
>
> For the SQL
> {code:java}
> select * from emp tablesample bernoulli(50) {code}
> selectivity is 1.0, maybe 0.5 will be better.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5944) RelMdRowCount can return more accurate rowCount for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-5944:
Summary: RelMdRowCount can return more accurate rowCount for Sample (was:
RelMdRowCount can return more accurate rowCount)
> RelMdRowCount can return more accurate rowCount for Sample
> --
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5944) RelMdRowCount can return more accurate rowCount
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-5944:
Description:
For the sql
{code:java}
select * from emp tablesample system(20) {code}
`mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
> RelMdRowCount can return more accurate rowCount
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5944) RelMdRowCount can return more accurate rowCount
Jiajun Xie created CALCITE-5944: --- Summary: RelMdRowCount can return more accurate rowCount Key: CALCITE-5944 URL: https://issues.apache.org/jira/browse/CALCITE-5944 Project: Calcite Issue Type: Improvement Components: core Reporter: Jiajun Xie Assignee: Jiajun Xie -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5943) RelMdSelectivity can return more precise selectivity for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756466#comment-17756466
]
Jiajun Xie commented on CALCITE-5943:
-
Selectivity is for predicate, maybe it is not suitable for sample.
I have a draft, but I'm not sure if it's necessary to implement it.
Welcome to leave your suggestion.
> RelMdSelectivity can return more precise selectivity for Sample
> ---
>
> Key: CALCITE-5943
> URL: https://issues.apache.org/jira/browse/CALCITE-5943
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
>
> For the SQL
> {code:java}
> select * from emp tablesample bernoulli(50) {code}
> selectivity is 1.0, maybe 0.5 will be better.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5943) RelMdSelectivity can return more precise selectivity for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-5943:
Issue Type: Improvement (was: Bug)
Priority: Minor (was: Major)
> RelMdSelectivity can return more precise selectivity for Sample
> ---
>
> Key: CALCITE-5943
> URL: https://issues.apache.org/jira/browse/CALCITE-5943
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
>
> For the SQL
> {code:java}
> select * from emp tablesample bernoulli(50) {code}
> selectivity is 1.0, maybe 0.5 will be better.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5943) RelMdSelectivity can return more precise selectivity for Sample
[ https://issues.apache.org/jira/browse/CALCITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie updated CALCITE-5943: Description: For the SQL ``` select * from emp tablesample bernoulli(50) ``` selectivity is 1.0, maybe 0.5 will be better. > RelMdSelectivity can return more precise selectivity for Sample > --- > > Key: CALCITE-5943 > URL: https://issues.apache.org/jira/browse/CALCITE-5943 > Project: Calcite > Issue Type: Bug >Reporter: Jiajun Xie >Assignee: Jiajun Xie >Priority: Major > > For the SQL > ``` > select * from emp tablesample bernoulli(50) > ``` > selectivity is 1.0, maybe 0.5 will be better. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5943) RelMdSelectivity can return more precise selectivity for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-5943:
Description:
For the SQL
{code:java}
select * from emp tablesample bernoulli(50) {code}
selectivity is 1.0, maybe 0.5 will be better.
was:
For the SQL
```
select * from emp tablesample bernoulli(50)
```
selectivity is 1.0, maybe 0.5 will be better.
> RelMdSelectivity can return more precise selectivity for Sample
> ---
>
> Key: CALCITE-5943
> URL: https://issues.apache.org/jira/browse/CALCITE-5943
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Major
>
> For the SQL
> {code:java}
> select * from emp tablesample bernoulli(50) {code}
> selectivity is 1.0, maybe 0.5 will be better.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5943) RelMdSelectivity can return more precise selectivity for Sample
Jiajun Xie created CALCITE-5943: --- Summary: RelMdSelectivity can return more precise selectivity for Sample Key: CALCITE-5943 URL: https://issues.apache.org/jira/browse/CALCITE-5943 Project: Calcite Issue Type: Bug Reporter: Jiajun Xie Assignee: Jiajun Xie -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-985) Validate MERGE
[ https://issues.apache.org/jira/browse/CALCITE-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie resolved CALCITE-985. Resolution: Fixed > Validate MERGE > -- > > Key: CALCITE-985 > URL: https://issues.apache.org/jira/browse/CALCITE-985 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Jiajun Xie >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > Now CALCITE-974 is fixed, we can validate INSERT, UPDATE and DELETE; > sql-to-rel conversion also succeeds, although I'm not sure we can execute. > MERGE does not yet pass validation. > I have added SqlToRelConverterTest.testMerge; we need one or two validator > fixes to make it pass. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-985) Validate MERGE
[ https://issues.apache.org/jira/browse/CALCITE-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756459#comment-17756459 ] Jiajun Xie commented on CALCITE-985: Fixed in [dc3f11b|https://github.com/apache/calcite/commit/dc3f11bf9b8c7814eaaf7cbbf96a24b0c2b50456]. [~julianhyde] , Thanks for your review. > Validate MERGE > -- > > Key: CALCITE-985 > URL: https://issues.apache.org/jira/browse/CALCITE-985 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Jiajun Xie >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > Now CALCITE-974 is fixed, we can validate INSERT, UPDATE and DELETE; > sql-to-rel conversion also succeeds, although I'm not sure we can execute. > MERGE does not yet pass validation. > I have added SqlToRelConverterTest.testMerge; we need one or two validator > fixes to make it pass. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5937) The parsing error should not be thrown even if there is no Hint in Hint Statement
[
https://issues.apache.org/jira/browse/CALCITE-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756454#comment-17756454
]
Jiajun Xie commented on CALCITE-5937:
-
[~shenlang], You didn't answer my question.
I think JIRA title can be better.
The parsing error should not be thrown even if there is *empty* Hint.
> The parsing error should not be thrown even if there is no Hint in Hint
> Statement
> -
>
> Key: CALCITE-5937
> URL: https://issues.apache.org/jira/browse/CALCITE-5937
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Attachments: image-2023-08-18-17-43-30-254.png,
> image-2023-08-19-21-01-52-505.png
>
>
> Hints are a special kind of SQL comment,so even if there is no Hint in Hint
> Statement,it should not throw the sql parser error.
> Now in the calcite,for the following sql query, it would throw an SQL parsing
> error:
> {code:java}
> select /*+ */ deptno, min(foo) as x from emp {code}
> The exception is :
> !image-2023-08-18-17-43-30-254.png|width=615,height=298!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5937) The parsing error should not be thrown even if there is no Hint in Hint Statement
[
https://issues.apache.org/jira/browse/CALCITE-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756257#comment-17756257
]
Jiajun Xie commented on CALCITE-5937:
-
[~shenlang], `no Hint` maybe strange.
WDYT? `if there is empty in hint`
> The parsing error should not be thrown even if there is no Hint in Hint
> Statement
> -
>
> Key: CALCITE-5937
> URL: https://issues.apache.org/jira/browse/CALCITE-5937
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Attachments: image-2023-08-18-17-43-30-254.png
>
>
> Hints are a special kind of SQL comment,so even if there is no Hint in Hint
> Statement,it should not throw the sql parser error.
> Now in the calcite,for the following sql query, it would throw an SQL parsing
> error:
> {code:java}
> select /*+ */ deptno, min(foo) as x from emp {code}
> The exception is :
> !image-2023-08-18-17-43-30-254.png|width=615,height=298!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5583) JDBC adapter generates 'SELECT *', which is invalid SQL if there are duplicate column names
[
https://issues.apache.org/jira/browse/CALCITE-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756255#comment-17756255
]
Jiajun Xie commented on CALCITE-5583:
-
[~leepb] , Thank you for your PR.
I have left some comments.
> JDBC adapter generates 'SELECT *', which is invalid SQL if there are
> duplicate column names
> ---
>
> Key: CALCITE-5583
> URL: https://issues.apache.org/jira/browse/CALCITE-5583
> Project: Calcite
> Issue Type: Bug
>Reporter: libopeng
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> JDBC adapter generates 'SELECT *', which is invalid SQL if there are
> duplicate column names
> {code:java}
> LogicalProject(c0=[$0], c00=[$1])
> LogicalJoin(condition=[=($0, $1)], joinType=[inner])
> LogicalProject(c0=[$0])
> LogicalTableScan(table=[[scott, EMP]])
> LogicalProject(c0=[$0])
> LogicalTableScan(table=[[scott, EMP]]){code}
> to sql
> {code:java}
> SELECT *
> FROM (SELECT "EMPNO" AS "c0"
> FROM "scott"."EMP") AS "t"
> INNER JOIN (SELECT "EMPNO" AS "c0"
> FROM "scott"."EMP") AS "t0" ON "t"."c0" = "t0"."c0" {code}
> When this sql is a subquery, it can be wrong
> {code:java}
> select *
> from "EMPNO" t1
> left join (
> SELECT * FROM (SELECT "EMPNO" AS "c0" FROM "scott"."EMP") AS "t" INNER JOIN
> (SELECT "EMPNO" AS "c0" FROM "scott"."EMP") AS "t0" ON "t"."c0" = "t0"."c0"
> ) t2
> on t1.EMPNO=t2."c0"{code}
> {color:#ff}fault: 'column reference "c0" is ambiguous' error when
> executing in postgresql{color}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5931) Fix integral number detection
[ https://issues.apache.org/jira/browse/CALCITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756248#comment-17756248 ] Jiajun Xie commented on CALCITE-5931: - [~cbrisson] Thank you for your commit, but we can do even better in something. # We don't like messages starting with Fix. Maybe we can use `Allow integers like 1.00 in window frame`. # Unit Test can make PR more popular, so you can write some cases ## 0.00 ## 1.00 ## Double.MAX_VALUE > Fix integral number detection > - > > Key: CALCITE-5931 > URL: https://issues.apache.org/jira/browse/CALCITE-5931 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Claude Brisson >Priority: Minor > Labels: pull-request-available > > When a number of rows is specified for a window, the code checks that the > provided literal is an integral number. > But the provided check leaves aside numbers like "1.00" (with a scale of 2, > but with trailing zeros). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5870) Allow literals like DECIMAL '12.3' (consistent with Postgres)
[
https://issues.apache.org/jira/browse/CALCITE-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756225#comment-17756225
]
Jiajun Xie commented on CALCITE-5870:
-
Fixed in
[f901d7d|https://github.com/apache/calcite/commit/f901d7d44a41e3a1db010c42dd4a422dcb31996c]
Thanks for the PR, [~shenlang]
Thanks for the review, [~julianhyde] and [~zstan]
> Allow literals like DECIMAL '12.3' (consistent with Postgres)
> -
>
> Key: CALCITE-5870
> URL: https://issues.apache.org/jira/browse/CALCITE-5870
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Attachments: image-2023-07-24-19-23-30-316.png,
> image-2023-07-24-19-26-44-131.png
>
>
> In Postgresql,It supports the following sql grammar:
> {code:java}
> select DECIMAL '99.999' {code}
> Postgresql converts DECIMAL '99.999' to numeric constants：
> !image-2023-07-24-19-23-30-316.png|width=399,height=186!
> Now core sql parser converts DECIMAL '99.999' to AS SqlBasicCall,like this:
> !image-2023-07-24-19-26-44-131.png|width=529,height=224!
> this jira allow literals like DECIMAL '12.3' (consistent with Postgres)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5870) Allow literals like DECIMAL '12.3' (consistent with Postgres)
[
https://issues.apache.org/jira/browse/CALCITE-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5870.
-
Resolution: Fixed
> Allow literals like DECIMAL '12.3' (consistent with Postgres)
> -
>
> Key: CALCITE-5870
> URL: https://issues.apache.org/jira/browse/CALCITE-5870
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Attachments: image-2023-07-24-19-23-30-316.png,
> image-2023-07-24-19-26-44-131.png
>
>
> In Postgresql,It supports the following sql grammar:
> {code:java}
> select DECIMAL '99.999' {code}
> Postgresql converts DECIMAL '99.999' to numeric constants：
> !image-2023-07-24-19-23-30-316.png|width=399,height=186!
> Now core sql parser converts DECIMAL '99.999' to AS SqlBasicCall,like this:
> !image-2023-07-24-19-26-44-131.png|width=529,height=224!
> this jira allow literals like DECIMAL '12.3' (consistent with Postgres)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5906) JDBC adapter should generate TABLESAMPLE
[
https://issues.apache.org/jira/browse/CALCITE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5906.
-
Resolution: Fixed
> JDBC adapter should generate TABLESAMPLE
>
>
> Key: CALCITE-5906
> URL: https://issues.apache.org/jira/browse/CALCITE-5906
> Project: Calcite
> Issue Type: Bug
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Attachments: image-2023-08-08-20-16-27-188.png,
> image-2023-08-08-20-19-01-269.png
>
>
> Currently in the RelToSqlConverter class, there is no visit method to handle
> the Sample RelNode.If a SQL plan has Sample RelNode, RelToSqlConverter will
> throw a AssertionError like this:
> {code:java}
> java.lang.AssertionError: Need to implement
> org.apache.calcite.rel.core.Sample
> {code}
> This will cause the Sample RelNode plan to fail to translate to the
> corresponding dialect.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5906) JDBC adapter should generate TABLESAMPLE
[
https://issues.apache.org/jira/browse/CALCITE-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754828#comment-17754828
]
Jiajun Xie commented on CALCITE-5906:
-
Fixed via
[51da34b.|https://github.com/apache/calcite/commit/51da34bdf91e602f32f965b3490bace026d51ef4]
Thank [~shenlang] for your PR.
Thank [~julianhyde] for your review.
> JDBC adapter should generate TABLESAMPLE
>
>
> Key: CALCITE-5906
> URL: https://issues.apache.org/jira/browse/CALCITE-5906
> Project: Calcite
> Issue Type: Bug
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Attachments: image-2023-08-08-20-16-27-188.png,
> image-2023-08-08-20-19-01-269.png
>
>
> Currently in the RelToSqlConverter class, there is no visit method to handle
> the Sample RelNode.If a SQL plan has Sample RelNode, RelToSqlConverter will
> throw a AssertionError like this:
> {code:java}
> java.lang.AssertionError: Need to implement
> org.apache.calcite.rel.core.Sample
> {code}
> This will cause the Sample RelNode plan to fail to translate to the
> corresponding dialect.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5830) Add ARRAY_INSERT function(enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-5830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754363#comment-17754363 ] Jiajun Xie commented on CALCITE-5830: - [~taoran] , I got it. Thank you for your detailed explanation. > Add ARRAY_INSERT function(enabled in Spark library) > --- > > Key: CALCITE-5830 > URL: https://issues.apache.org/jira/browse/CALCITE-5830 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.34.0 >Reporter: Ran Tao >Assignee: Ran Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2023-08-14-11-17-33-205.png, > image-2023-08-14-11-20-46-189.png > > > array_insert(x, pos, val) - Places val into index pos of array x. Array > indices start at 1, or start from the end if index is negative. Index above > array size appends the array, or prepends the array if index is negative, > with 'null' elements > *Examples:* > > SELECT array_insert(array(1, 2, 3, 4), 5, 5); [1,2,3,4,5] > > SELECT array_insert(array(5, 3, 2, 1), -3, 4); [5,4,3,2,1] > https://spark.apache.org/docs/latest/api/sql/index.html#array_insert -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5830) Add ARRAY_INSERT function(enabled in Spark library)
[
https://issues.apache.org/jira/browse/CALCITE-5830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753673#comment-17753673
]
Jiajun Xie commented on CALCITE-5830:
-
[~taoran] , ARRAY_INSERT is a function only available in the latest version of
Spark. Is it really stable?
I found that it is not the same in Databricks:
https://docs.databricks.com/en/sql/language-manual/functions/array_insert.html
{code:java}
> SELECT array_insert(array('a', 'b', 'c'), -1, 'z');
["a","b","c","z"]
> SELECT array_insert(array('a', 'b', 'c'), -5, 'z');
["z",NULL,"a","b","c"] {code}
I think inserting negative numbers is more reasonable in Databricks.
> Add ARRAY_INSERT function(enabled in Spark library)
> ---
>
> Key: CALCITE-5830
> URL: https://issues.apache.org/jira/browse/CALCITE-5830
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.34.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
>
> array_insert(x, pos, val) - Places val into index pos of array x. Array
> indices start at 1, or start from the end if index is negative. Index above
> array size appends the array, or prepends the array if index is negative,
> with 'null' elements
> *Examples:*
> > SELECT array_insert(array(1, 2, 3, 4), 5, 5); [1,2,3,4,5]
> > SELECT array_insert(array(5, 3, 2, 1), -3, 4); [5,4,3,2,1]
> https://spark.apache.org/docs/latest/api/sql/index.html#array_insert
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5813) Type inference for sql functions REPEAT, SPACE, XML_TRANSFORM, and XML_EXTRACT is incorrect
[
https://issues.apache.org/jira/browse/CALCITE-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753481#comment-17753481
]
Jiajun Xie commented on CALCITE-5813:
-
Fixed in
[ed42c35|https://github.com/apache/calcite/commit/ed42c35bd1a357dd0b5d5dc268e93573b724a800],
Thank [~mbudiu] for your PR.
> Type inference for sql functions REPEAT, SPACE, XML_TRANSFORM, and
> XML_EXTRACT is incorrect
> ---
>
> Key: CALCITE-5813
> URL: https://issues.apache.org/jira/browse/CALCITE-5813
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> The result of the following SQL query (enabling the proper dialects for the
> REPEAT function):
> {code:sql}
> SELECT REPEAT('abc', 2)
> {code}
> is incorrectly computed by Calcite as 'abc' (no repetitions) if the constant
> folding optimization PROJECT_REDUCE_EXPRESSIONS is enabled.
> (I am not sure exactly how to modify the operator tables of the
> RelOptFixture, so I had to jump through some hoops to create a simple
> reproduction.)
> The plans before and after are as following:
> {code:java}
> LogicalProject(EXPR$0=[REPEAT('abc', 2)])
> LogicalValues(tuples=[[{ 0 }]])
> ---
> LogicalProject(EXPR$0=['abc':VARCHAR(3)])
> LogicalValues(tuples=[[{ 0 }]])
> {code}
> The root cause is the following:
> In the definition of the REPEAT SqlFunction:
> {code:java}
> @LibraryOperator(libraries = {BIG_QUERY, MYSQL, POSTGRESQL})
> public static final SqlFunction REPEAT =
> SqlBasicFunction.create("REPEAT",
> ReturnTypes.ARG0_NULLABLE_VARYING, /// <<< WRONG
> OperandTypes.STRING_INTEGER,
> SqlFunctionCategory.STRING);
> {code}
> the output type is the same as the first argument type. If the first argument
> type is VARCHAR(N), the output type is also VARCHAR(N). This causes the
> optimizer to first correctly compute the repeated string and then truncate
> result to the original length.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5813) Type inference for sql functions REPEAT, SPACE, XML_TRANSFORM, and XML_EXTRACT is incorrect
[
https://issues.apache.org/jira/browse/CALCITE-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5813.
-
Resolution: Fixed
> Type inference for sql functions REPEAT, SPACE, XML_TRANSFORM, and
> XML_EXTRACT is incorrect
> ---
>
> Key: CALCITE-5813
> URL: https://issues.apache.org/jira/browse/CALCITE-5813
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> The result of the following SQL query (enabling the proper dialects for the
> REPEAT function):
> {code:sql}
> SELECT REPEAT('abc', 2)
> {code}
> is incorrectly computed by Calcite as 'abc' (no repetitions) if the constant
> folding optimization PROJECT_REDUCE_EXPRESSIONS is enabled.
> (I am not sure exactly how to modify the operator tables of the
> RelOptFixture, so I had to jump through some hoops to create a simple
> reproduction.)
> The plans before and after are as following:
> {code:java}
> LogicalProject(EXPR$0=[REPEAT('abc', 2)])
> LogicalValues(tuples=[[{ 0 }]])
> ---
> LogicalProject(EXPR$0=['abc':VARCHAR(3)])
> LogicalValues(tuples=[[{ 0 }]])
> {code}
> The root cause is the following:
> In the definition of the REPEAT SqlFunction:
> {code:java}
> @LibraryOperator(libraries = {BIG_QUERY, MYSQL, POSTGRESQL})
> public static final SqlFunction REPEAT =
> SqlBasicFunction.create("REPEAT",
> ReturnTypes.ARG0_NULLABLE_VARYING, /// <<< WRONG
> OperandTypes.STRING_INTEGER,
> SqlFunctionCategory.STRING);
> {code}
> the output type is the same as the first argument type. If the first argument
> type is VARCHAR(N), the output type is also VARCHAR(N). This causes the
> optimizer to first correctly compute the repeated string and then truncate
> result to the original length.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5885) SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on nested types
[
https://issues.apache.org/jira/browse/CALCITE-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5885.
-
Fix Version/s: 1.36.0
Resolution: Fixed
> SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on
> nested types
> -
>
> Key: CALCITE-5885
> URL: https://issues.apache.org/jira/browse/CALCITE-5885
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Chris Rice
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Attachments: CharsetTest.java
>
>
> Say we generate a RelNode corresponding to
> {code:java}
> SELECT CAST(c AS VARCHAR) FROM t
> {code}
> and we were to "unparse" that rel node back into the Postgres SQL dialect
> using
> {code:java}
> var converter = new RelToSqlConverter(PostgresqlSqlDialect.DEFAULT);
> SqlImplementor.Result result = converter.visitRoot(rel);
> SqlNode sqlNode = result.asStatement();
> var sql = sqlNode.toSqlString(PostgresqlSqlDialect.DEFAULT).getSql();
> {code}
> it would generate something like:
> {code:java}
> SELECT CAST("c" AS VARCHAR) AS "c"
> FROM "t"
> {code}
> Note that there is no charset information included in the cast, since the
> {{PostgresSqlDialect}} specifies that it does not support char sets:
> {code:java}
> @Override public boolean supportsCharSet() {
> return false;
> }
> {code}
> Given that, we would expect that unparsing
> {code:java}
> SELECT CAST(c AS VARCHAR ARRAY) FROM t
> {code}
> back into SQL would also generate a type with no charset specified, but it in
> fact generates
> {code:java}
> SELECT CAST("c" AS VARCHAR CHARACTER SET "ISO-8859-1" ARRAY) AS "c"
> FROM "t"
> {code}
> This seems to come from the way `SqlTypeUtil.convertTypeToSpec()` handles
> collection types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5885) SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on nested types
[
https://issues.apache.org/jira/browse/CALCITE-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753012#comment-17753012
]
Jiajun Xie commented on CALCITE-5885:
-
Fixed in
[6974126|https://github.com/apache/calcite/commit/697412624ef6baf0bf94554a51a5f7ed54d09ce7],
thank [~chrisrice] for your review.
> SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on
> nested types
> -
>
> Key: CALCITE-5885
> URL: https://issues.apache.org/jira/browse/CALCITE-5885
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Chris Rice
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
> Attachments: CharsetTest.java
>
>
> Say we generate a RelNode corresponding to
> {code:java}
> SELECT CAST(c AS VARCHAR) FROM t
> {code}
> and we were to "unparse" that rel node back into the Postgres SQL dialect
> using
> {code:java}
> var converter = new RelToSqlConverter(PostgresqlSqlDialect.DEFAULT);
> SqlImplementor.Result result = converter.visitRoot(rel);
> SqlNode sqlNode = result.asStatement();
> var sql = sqlNode.toSqlString(PostgresqlSqlDialect.DEFAULT).getSql();
> {code}
> it would generate something like:
> {code:java}
> SELECT CAST("c" AS VARCHAR) AS "c"
> FROM "t"
> {code}
> Note that there is no charset information included in the cast, since the
> {{PostgresSqlDialect}} specifies that it does not support char sets:
> {code:java}
> @Override public boolean supportsCharSet() {
> return false;
> }
> {code}
> Given that, we would expect that unparsing
> {code:java}
> SELECT CAST(c AS VARCHAR ARRAY) FROM t
> {code}
> back into SQL would also generate a type with no charset specified, but it in
> fact generates
> {code:java}
> SELECT CAST("c" AS VARCHAR CHARACTER SET "ISO-8859-1" ARRAY) AS "c"
> FROM "t"
> {code}
> This seems to come from the way `SqlTypeUtil.convertTypeToSpec()` handles
> collection types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5904) The result should be empty list when table sample rate is 0
[
https://issues.apache.org/jira/browse/CALCITE-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17752264#comment-17752264
]
Jiajun Xie commented on CALCITE-5904:
-
You closed it, do you plan to create new PR?
> The result should be empty list when table sample rate is 0
> ---
>
> Key: CALCITE-5904
> URL: https://issues.apache.org/jira/browse/CALCITE-5904
> Project: Calcite
> Issue Type: Sub-task
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> For The sql:
> {code:java}
> select * from emp tablesample bernoulli(0) where empno > 5
> {code}
> The plan is :
> {code:java}
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalFilter(condition=[>($0, 5)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> I think the correct result of above SQL is empty.
> But its result is the following SQL result:
> {code:java}
> select * from emp where empno > 5
> {code}
> It's an incorrect result
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5885) SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on nested types
[
https://issues.apache.org/jira/browse/CALCITE-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751368#comment-17751368
]
Jiajun Xie commented on CALCITE-5885:
-
Hi, [~chrisrice]
I fixed it, welcome to review it:
https://github.com/apache/calcite/pull/3349/files
> SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on
> nested types
> -
>
> Key: CALCITE-5885
> URL: https://issues.apache.org/jira/browse/CALCITE-5885
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Chris Rice
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
> Attachments: CharsetTest.java
>
>
> Say we generate a RelNode corresponding to
> {code:java}
> SELECT CAST(c AS VARCHAR) FROM t
> {code}
> and we were to "unparse" that rel node back into the Postgres SQL dialect
> using
> {code:java}
> var converter = new RelToSqlConverter(PostgresqlSqlDialect.DEFAULT);
> SqlImplementor.Result result = converter.visitRoot(rel);
> SqlNode sqlNode = result.asStatement();
> var sql = sqlNode.toSqlString(PostgresqlSqlDialect.DEFAULT).getSql();
> {code}
> it would generate something like:
> {code:java}
> SELECT CAST("c" AS VARCHAR) AS "c"
> FROM "t"
> {code}
> Note that there is no charset information included in the cast, since the
> {{PostgresSqlDialect}} specifies that it does not support char sets:
> {code:java}
> @Override public boolean supportsCharSet() {
> return false;
> }
> {code}
> Given that, we would expect that unparsing
> {code:java}
> SELECT CAST(c AS VARCHAR ARRAY) FROM t
> {code}
> back into SQL would also generate a type with no charset specified, but it in
> fact generates
> {code:java}
> SELECT CAST("c" AS VARCHAR CHARACTER SET "ISO-8859-1" ARRAY) AS "c"
> FROM "t"
> {code}
> This seems to come from the way `SqlTypeUtil.convertTypeToSpec()` handles
> collection types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-5885) SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on nested types
[
https://issues.apache.org/jira/browse/CALCITE-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie reassigned CALCITE-5885:
---
Assignee: Jiajun Xie
> SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on
> nested types
> -
>
> Key: CALCITE-5885
> URL: https://issues.apache.org/jira/browse/CALCITE-5885
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Chris Rice
>Assignee: Jiajun Xie
>Priority: Minor
> Attachments: CharsetTest.java
>
>
> Say we generate a RelNode corresponding to
> {code:java}
> SELECT CAST(c AS VARCHAR) FROM t
> {code}
> and we were to "unparse" that rel node back into the Postgres SQL dialect
> using
> {code:java}
> var converter = new RelToSqlConverter(PostgresqlSqlDialect.DEFAULT);
> SqlImplementor.Result result = converter.visitRoot(rel);
> SqlNode sqlNode = result.asStatement();
> var sql = sqlNode.toSqlString(PostgresqlSqlDialect.DEFAULT).getSql();
> {code}
> it would generate something like:
> {code:java}
> SELECT CAST("c" AS VARCHAR) AS "c"
> FROM "t"
> {code}
> Note that there is no charset information included in the cast, since the
> {{PostgresSqlDialect}} specifies that it does not support char sets:
> {code:java}
> @Override public boolean supportsCharSet() {
> return false;
> }
> {code}
> Given that, we would expect that unparsing
> {code:java}
> SELECT CAST(c AS VARCHAR ARRAY) FROM t
> {code}
> back into SQL would also generate a type with no charset specified, but it in
> fact generates
> {code:java}
> SELECT CAST("c" AS VARCHAR CHARACTER SET "ISO-8859-1" ARRAY) AS "c"
> FROM "t"
> {code}
> This seems to come from the way `SqlTypeUtil.convertTypeToSpec()` handles
> collection types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5813) Type inference for REPEAT sql function is incorrect
[
https://issues.apache.org/jira/browse/CALCITE-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750926#comment-17750926
]
Jiajun Xie commented on CALCITE-5813:
-
Hi, [~mbudiu].
The PR looks good, you also fixed SPACE, XML_TRANSFORM, and XML_EXTRACT
functions.
So Jira title(Type inference for REPEAT sql function is incorrect) is not
enough, please change it.
> Type inference for REPEAT sql function is incorrect
> ---
>
> Key: CALCITE-5813
> URL: https://issues.apache.org/jira/browse/CALCITE-5813
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> The result of the following SQL query (enabling the proper dialects for the
> REPEAT function):
> {code:sql}
> SELECT REPEAT('abc', 2)
> {code}
> is incorrectly computed by Calcite as 'abc' (no repetitions) if the constant
> folding optimization PROJECT_REDUCE_EXPRESSIONS is enabled.
> (I am not sure exactly how to modify the operator tables of the
> RelOptFixture, so I had to jump through some hoops to create a simple
> reproduction.)
> The plans before and after are as following:
> {code:java}
> LogicalProject(EXPR$0=[REPEAT('abc', 2)])
> LogicalValues(tuples=[[{ 0 }]])
> ---
> LogicalProject(EXPR$0=['abc':VARCHAR(3)])
> LogicalValues(tuples=[[{ 0 }]])
> {code}
> The root cause is the following:
> In the definition of the REPEAT SqlFunction:
> {code:java}
> @LibraryOperator(libraries = {BIG_QUERY, MYSQL, POSTGRESQL})
> public static final SqlFunction REPEAT =
> SqlBasicFunction.create("REPEAT",
> ReturnTypes.ARG0_NULLABLE_VARYING, /// <<< WRONG
> OperandTypes.STRING_INTEGER,
> SqlFunctionCategory.STRING);
> {code}
> the output type is the same as the first argument type. If the first argument
> type is VARCHAR(N), the output type is also VARCHAR(N). This causes the
> optimizer to first correctly compute the repeated string and then truncate
> result to the original length.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-3697) Implement BITCOUNT scalar function
[ https://issues.apache.org/jira/browse/CALCITE-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748903#comment-17748903 ] Jiajun Xie commented on CALCITE-3697: - [~x1q1j1] Would you please solve conflicting files? > Implement BITCOUNT scalar function > -- > > Key: CALCITE-3697 > URL: https://issues.apache.org/jira/browse/CALCITE-3697 > Project: Calcite > Issue Type: Sub-task >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Implement bit_count function -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5835) SqlParser.parseQuery() successfully parses DML and DDL statements without throwing a SqlParseException
[
https://issues.apache.org/jira/browse/CALCITE-5835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748890#comment-17748890
]
Jiajun Xie commented on CALCITE-5835:
-
Make sense. `top-level SqlNode representing stmt` is more accurate than
`{{{}SqlSelect{}}} or {{{}SqlBinaryOperator{}}}`.
[~ankitsiva], Welcome to contribute.
> SqlParser.parseQuery() successfully parses DML and DDL statements without
> throwing a SqlParseException
> --
>
> Key: CALCITE-5835
> URL: https://issues.apache.org/jira/browse/CALCITE-5835
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Ankit Siva
>Priority: Major
>
> I've set up a parser as follows:
>
> {code:java}
> val config= SqlParser.config()
> .withConformance(SqlConformanceEnum.BABEL)
> .withQuoting(Quoting.DOUBLE_QUOTE)
> .withQuotedCasing(Casing.TO_LOWER)
> .withUnquotedCasing(Casing.TO_LOWER)
> .withCaseSensitive(false)
> val parser = SqlParser.create(sql, config)
> parser.parseQuery()
> {code}
>
> I am parsing the following statements:
> 1.
> {code:java}
> INSERT INTO Customers (CustomerName, ContactName, Address, City, PostalCode,
> Country)
> VALUES ('Cardinal', 'Tom B. Erichsen', 'Skagen 21', 'Stavanger', '4006',
> 'Norway'){code}
> 2.
> {code:java}
> INSERT INTO emps (emp_id , emp_name , emp_salary)
> SELECT employee_id , last_name , salary
> FROM employees
> WHERE department_id = 50{code}
> 3.
> {code:java}
> UPDATE employees
> SET salary = 5000
> WHERE employee_id = 100{code}
> 4.
> {code:java}
> DELETE FROM employees
> WHERE department_id = (
> SELECT department_id FROM departments
> WHERE department_name = 'Sales'
> ){code}
> 5.
> {code:java}
> MERGE INTO customers_backup bkup
> USING customers cust
> ON (bkup.cust_id = cust.cust_id)
> WHEN MATCHED THEN
> UPDATE SET
> bkup.cust_name = cust.cust_name ,
> bkup.cust_surfing_package = cust.cust_surfing_package
> WHEN NOT MATCHED THEN
> INSERT VALUES(cust.cust_id , cust.cust_name , cust.cust_surfing_package){code}
> Parsing any of these queries does not raise a `SqlParseException`.
> Additionally, these return nodes that are not of type {{SqlSelect}} or
> {{{}SqlBinaryOperator{}}}. This conflicts with the expectation of the method
> and the contract declared in the
> [javadoc|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/parser/SqlParser.html#parseQuery()].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5688) Support TRUNCATE TABLE DDL statement in server module
[
https://issues.apache.org/jira/browse/CALCITE-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746144#comment-17746144
]
Jiajun Xie commented on CALCITE-5688:
-
[~julianhyde] , so sorry.
I should check the server parser, not just the core parser (There are no
warning in core parser).
New commit eliminates warnings: https://github.com/apache/calcite/pull/3335
> Support TRUNCATE TABLE DDL statement in server module
> -
>
> Key: CALCITE-5688
> URL: https://issues.apache.org/jira/browse/CALCITE-5688
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Reporter: Sumeet
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> Calcite should support parse truncate syntax like SQL2011
> {code:java}
> ::=
> TRUNCATE TABLE [ ]
> ::=
> CONTINUE IDENTITY
> | RESTART IDENTITY {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5844) Make RelMdColumnOrigins to be extendable for getting columnOrigins from viewTable
[
https://issues.apache.org/jira/browse/CALCITE-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746001#comment-17746001
]
Jiajun Xie commented on CALCITE-5844:
-
ViewTable will be expanded during query planning.
[~jingda] Are you using `RelMdColumnOrigins#getColumnOrigins` after closing
View expansion?
> Make RelMdColumnOrigins to be extendable for getting columnOrigins from
> viewTable
> -
>
> Key: CALCITE-5844
> URL: https://issues.apache.org/jira/browse/CALCITE-5844
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: JingDas
>Priority: Minor
>
> In our scene, Getting field from view is expected when call
> RelMdColumnOrigins#getColumnOrigins.
> So I want to define customized RelMdColumnOrigins extend *RelMdColumnOrigins*
> which can *getColumnOrigins* from viewTable.
> Then I add customized RelMdColumnOrigins to {*}ChainedRelMetadataProvider{*},
> keep the sequence before DefaultRelMetadataProvider.INSTANCE.
> After doing all above, I can get columnOrigins from viewTable.
>
> But I found the private modifier constructor in class RelMdColumnOrigins(also
> such as
> RelMdCollation, RelMdColumnUniqueness, RelMdDistribution,
> RelMdExplainVisibility,
> RelMdPercentageOriginalRows, RelMdPopulationSize, RelMdUniqueKeys
> ),
> and protected modifier constructors(such as RelMdDistinctRowCount,
> RelMdExpressionLineage, RelMdLowerBoundCost,
> RelMdMemory, RelMdParallelism, RelMdSelectivity, RelMdSize,
> RelMdTableReferences
> )
> and public modifier constructors(such as RelMdAllPredicates,
> RelMdMaxRowCount, RelMdMinRowCount, RelMdNodeTypes,
> RelMdPredicates, RelMdRowCount,
> )
> I haven't had a chance to extend this class to add my custom logic because
> the constructor modifier is private.
> These "RelMd"prefixed class are default implementation, They should can be
> extended for user to add
> customed logic.
> For extensibility, I think this modifier maybe protected for these
> "RelMd"prefixed class whose modifier is private.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-4455) Babel parser support Spark INSERT OVERWRITE TABLE/DIRECTORY statement
[
https://issues.apache.org/jira/browse/CALCITE-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741233#comment-17741233
]
Jiajun Xie commented on CALCITE-4455:
-
I implemented TRUNCATE TABLE statement that is DDL in CALCITE-5688.
`SqlKind.OTHER_DML` is not needed, so I use `SqlKind.INSERT_OVERWRITE`.
> Babel parser support Spark INSERT OVERWRITE TABLE/DIRECTORY statement
> -
>
> Key: CALCITE-4455
> URL: https://issues.apache.org/jira/browse/CALCITE-4455
> Project: Calcite
> Issue Type: Sub-task
> Components: spark
>Reporter: shradha
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Spark has [INSERT OVERWRITE TABLE
> statement|https://spark.apache.org/docs/3.1.2/sql-ref-syntax-dml-insert-overwrite-table.html]
> and [INSERT OVERWRITE DIRECTORY
> statement|https://spark.apache.org/docs/3.1.2/sql-ref-syntax-dml-insert-overwrite-directory.html].
>
> We can support part of their grammar, here is syntax that babel parser used:
> - INSERT OVERWRITE TABLE
> -- Syntax
> {code:java}
> INSERT OVERWRITE TABLE table_identifier [ partition_spec [ IF NOT EXISTS ] ]
> [ ( column_list ) ]
> { VALUES ( { value | NULL } [ , ... ] ) [ , ( ... ) ] | query } {code}
> -- Example
> {code:java}
> -- Insert Using a SELECT Statement
> INSERT OVERWRITE TABLE students PARTITION (student_id = 22)
> SELECT name, address FROM persons WHERE name = "Dora Williams";
> -- Insert Using a SELECT Statement with column list and omit partition
> INSERT OVERWRITE TABLE target (c1) SELECT * FROM source
> -- Insert Using a VALUES Clause
> INSERT OVERWRITE TABLE students
> VALUES ('Ashua Hill', '456 Erica Ct, Cupertino', 11),
>('Brian Reed', '723 Kern Ave, Palo Alto', 22); {code}
> - INSERT OVERWRITE DIRECTORY
> -- Syntax
> {code:java}
> INSERT OVERWRITE [ LOCAL ] DIRECTORY directory_path
> USING file_format [ OPTIONS ( key = val [ , ... ] ) ]
> { VALUES ( { value | NULL } [ , ... ] ) [ , ( ... ) ] | query }{code}
> -- Example
> {code:java}
> INSERT OVERWRITE DIRECTORY '/tmp/destination'
> USING parquet
> OPTIONS (col1=1, col2=2, col3='test')
> SELECT * FROM test_table;
> -- omit options
> INSERT OVERWRITE DIRECTORY '/tmp/destination'
> USING parquet
> SELECT * FROM test_table;{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5688) Support TRUNCATE TABLE DDL statement in server module
[
https://issues.apache.org/jira/browse/CALCITE-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740376#comment-17740376
]
Jiajun Xie commented on CALCITE-5688:
-
Fixed in
[fb6f431|https://github.com/apache/calcite/commit/fb6f43192c4253caea63c0705067a9aa12a3fa74].
Thanks for the PR [~sumeet.gajjar].
Thanks for your review [~VAE].
> Support TRUNCATE TABLE DDL statement in server module
> -
>
> Key: CALCITE-5688
> URL: https://issues.apache.org/jira/browse/CALCITE-5688
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Reporter: Sumeet
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> Calcite should support parse truncate syntax like SQL2011
> {code:java}
> ::=
> TRUNCATE TABLE [ ]
> ::=
> CONTINUE IDENTITY
> | RESTART IDENTITY {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5688) Support TRUNCATE TABLE DDL statement in server module
[
https://issues.apache.org/jira/browse/CALCITE-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5688.
-
Fix Version/s: 1.35.0
Resolution: Fixed
> Support TRUNCATE TABLE DDL statement in server module
> -
>
> Key: CALCITE-5688
> URL: https://issues.apache.org/jira/browse/CALCITE-5688
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Reporter: Sumeet
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> Calcite should support parse truncate syntax like SQL2011
> {code:java}
> ::=
> TRUNCATE TABLE [ ]
> ::=
> CONTINUE IDENTITY
> | RESTART IDENTITY {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5799) unnest(a) is wrong if a is structKind.PEEK_FIELDS_NO_EXPAND
[ https://issues.apache.org/jira/browse/CALCITE-5799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739338#comment-17739338 ] Jiajun Xie commented on CALCITE-5799: - Maybe CALCITE-5126 can solve the issue. [~pyro] , can you use calcite >= 1.32 to reproduce the it? > unnest(a) is wrong if a is structKind.PEEK_FIELDS_NO_EXPAND > > > Key: CALCITE-5799 > URL: https://issues.apache.org/jira/browse/CALCITE-5799 > Project: Calcite > Issue Type: Bug >Reporter: Haojin Wang >Priority: Critical > > when I validate sql "select * from MyTable,UNNEST(N2.D)", throw > "org.apache.calcite.runtime.CalciteContextException: From line 0, column 0 to > line 1, column 31: Column 'N2.N2' not found in table 'MYTABLE'" I think this > is weird. > > myTable( > * a: BIGINT, > * n1: STRUCT< > * n11: STRUCT, > * n12: STRUCT > * >, > * n2: STRUCT, > * e: BIGINT) -- This message was sent by Atlassian Jira (v8.20.10#820010)
