[jira] [Commented] (CALCITE-3087) Mappings.apply2 doesn't keep order
[
https://issues.apache.org/jira/browse/CALCITE-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854227#comment-16854227
]
Feng Zhu commented on CALCITE-3087:
---
Hi, [~hyuan]. I think we need to check whether the mapping keeps order in
*{{AggregateOnProjectToAggregateUnifyRule}}*. According to the rule's
description:
"
{color:#808080}The rule is necessary when we unify query=Aggregate(x)
with{color}{color:#808080} target=Aggregate(x, y). Query will tend to have an
extra Project(x) on its {color}{color:#808080}input, which this rule knows
{color:#FF}is safe to ignore{color}.{color}
"
However, when the Project mapping changes the field's order, it cannot be
ignored. Even we sort groupsets in such case, the rowtype of new created
result (MultableAggregate) is different to the query.
{code:java}
Result: RecordType(JavaType(class java.lang.Integer) empid, JavaType(class
java.lang.Integer) deptno, BIGINT $f2)
Query: RecordType(JavaType(class java.lang.Integer) deptno, JavaType(class
java.lang.Integer) empid, BIGINT $f2)
{code}
Moreover, I noticed that some assertions need to be added to ensure ordering in
*MultableAggregate*, as that in *Aggregate:*
{code:java}
assert ImmutableBitSet.ORDERING.isStrictlyOrdered(groupSets) : groupSets;
for (ImmutableBitSet set : groupSets) {
assert groupSet.contains(set);
}
assert groupSet.length() <= child.getRowType().getFieldCount();
{code}
> Mappings.apply2 doesn't keep order
> --
>
> Key: CALCITE-3087
> URL: https://issues.apache.org/jira/browse/CALCITE-3087
> Project: Calcite
> Issue Type: Bug
>Reporter: Haisheng Yuan
>Priority: Major
>
> Add the following test to MaterializationTest:
> {code:java}
> @Test public void testAggregateGroupSetsRollUp0() {
> checkMaterialize(
> "select \"empid\", \"deptno\", count(*) as c, sum(\"salary\") as s
> from \"emps\" "
> + "group by \"empid\", \"deptno\"",
> "select count(*) + 1 as c, \"deptno\" from \"emps\" group by
> cube(\"deptno\", \"empid\")",
> HR_FKUK_MODEL,
> CalciteAssert.checkResultContains(
> "EnumerableCalc(expr#0..2=[{inputs}], expr#3=[1], "
> + "expr#4=[+($t2, $t3)], C=[$t4], deptno=[$t1])\n"
> + " EnumerableAggregate(group=[{0, 1}], groups=[[{0, 1},
> {0}, {1}, {}]], agg#0=[$SUM0($2)])\n"
> + "EnumerableTableScan(table=[[hr, m0]])"));
> }
> {code}
> We got error:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: must be sorted: [{0, 1}, {1},
> {0}, {}]
> at
> org.apache.calcite.rel.core.Aggregate$Group.induce(Aggregate.java:472)
> at
> org.apache.calcite.rel.mutable.MutableAggregate.getGroupType(MutableAggregate.java:83)
> at
> org.apache.calcite.plan.SubstitutionVisitor.unifyAggregates(SubstitutionVisitor.java:1281)
> at
> org.apache.calcite.plan.SubstitutionVisitor$AggregateOnProjectToAggregateUnifyRule.apply(SubstitutionVisitor.java:1345)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:531)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:466)
> at
> org.apache.calcite.plan.MaterializedViewSubstitutionVisitor.go(MaterializedViewSubstitutionVisitor.java:56)
> at
> org.apache.calcite.plan.RelOptMaterializations.substitute(RelOptMaterializations.java:200)
> at
> org.apache.calcite.plan.RelOptMaterializations.useMaterializedViews(RelOptMaterializations.java:72)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerMaterializations(VolcanoPlanner.java:348)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:584)
> {code}
> The reason is that Mappings.apply2 doesn't sort.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854165#comment-16854165 ] Jiatao Tao edited comment on CALCITE-3065 at 6/3/19 2:52 AM: - Hi [~julianhyde] truly thanks for your explanation. Seems the name "getJavaClass" is a little confusing, it only does a little thing, not a universal API. And in my opinion, an API that can get class from "RelDataType" is useful, so that I can easily get the true value from RexLiteral though getValueAs. And seems that the value that "RexLiteral.getValueAs" returns are all nullable, it may diff from its ori type. was (Author: aron.tao): Hi [~julianhyde] truly thanks for your explanation. Seems the name "getJavaClass" is a little confusing, it only does a little thing, not a universal API. And seems that the value that "RexLiteral.getValueAs" returns are all nullable(although we can get this from SqlType). > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png, > image-2019-06-02-08-43-51-646.png > > Time Spent: 50m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854165#comment-16854165 ] Jiatao Tao commented on CALCITE-3065: - Hi [~julianhyde] truly thanks for your explanation. Seems the name "getJavaClass" is a little confusing, it only does a little thing, not a universal API. And seems that the value that "RexLiteral.getValueAs" returns are all nullable(although we can get this from SqlType). > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png, > image-2019-06-02-08-43-51-646.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3005) Implement string functions: LEFT, RIGHT
[
https://issues.apache.org/jira/browse/CALCITE-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854121#comment-16854121
]
Julian Hyde commented on CALCITE-3005:
--
Reviewing revised PR now.
> Implement string functions: LEFT, RIGHT
> ---
>
> Key: CALCITE-3005
> URL: https://issues.apache.org/jira/browse/CALCITE-3005
> Project: Calcite
> Issue Type: New Feature
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> Some string functions including LEFT, RIGHT are not implemented now. It would
> be great if these functions can be implemented.
> [{{LEFT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_left]
> Returns the leftmost _{{len}}_ characters from the string _{{str}}_, or
> {{NULL}} if any argument is {{NULL}}.
> [{{RIGHT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_right]
> Returns the rightmost _{{len}}_ characters from the string _{{str}}_, or
> {{NULL}} if any argument is {{NULL}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3107) Bump commons-dbcp2 from 2.5.0 to 2.6.0
[ https://issues.apache.org/jira/browse/CALCITE-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-3107: - Fix Version/s: 1.20.0 > Bump commons-dbcp2 from 2.5.0 to 2.6.0 > -- > > Key: CALCITE-3107 > URL: https://issues.apache.org/jira/browse/CALCITE-3107 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Fokko Driesprong >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3106) Bump commons-pool2 from 2.6.0 to 2.6.2
[ https://issues.apache.org/jira/browse/CALCITE-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-3106: - Fix Version/s: 1.20.0 > Bump commons-pool2 from 2.6.0 to 2.6.2 > -- > > Key: CALCITE-3106 > URL: https://issues.apache.org/jira/browse/CALCITE-3106 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Fokko Driesprong >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3107) Bump commons-dbcp2 from 2.5.0 to 2.6.0
[ https://issues.apache.org/jira/browse/CALCITE-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854053#comment-16854053 ] Julian Hyde commented on CALCITE-3107: -- Reviewing and testing now. > Bump commons-dbcp2 from 2.5.0 to 2.6.0 > -- > > Key: CALCITE-3107 > URL: https://issues.apache.org/jira/browse/CALCITE-3107 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Fokko Driesprong >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3106) Bump commons-pool2 from 2.6.0 to 2.6.2
[ https://issues.apache.org/jira/browse/CALCITE-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854054#comment-16854054 ] Julian Hyde commented on CALCITE-3106: -- Reviewing and testing now. > Bump commons-pool2 from 2.6.0 to 2.6.2 > -- > > Key: CALCITE-3106 > URL: https://issues.apache.org/jira/browse/CALCITE-3106 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Fokko Driesprong >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[
https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854037#comment-16854037
]
Julian Hyde commented on CALCITE-3065:
--
{{getJavaClass}} is a specialized piece of code only for purposes where we are
implementing a plan as java code (i.e. enumerable convention). It does not
apply to the whole type system, which applies also to plans that are
implemented by generating SQL to be sent over JDBC, or generating Druid plans,
or whatever.
There are many cases where the representation of a literal in generated java
code is not the same as the representation inside a {{RexLiteral}}.
So, the behavior of {{getJavaClass}} doesn't prove anything. You can't use it
to justify changes to the behavior of {{RexLiteral}}.
> RexLiteral#getValueAs should consider primitive type
>
>
> Key: CALCITE-3065
> URL: https://issues.apache.org/jira/browse/CALCITE-3065
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2019-05-13-12-04-36-365.png,
> image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png,
> image-2019-06-02-08-43-51-646.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> !image-2019-05-13-12-04-36-365.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3108) Babel parser should parse the PostgreSQL TEXT type
[
https://issues.apache.org/jira/browse/CALCITE-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853916#comment-16853916
]
Muhammad Gelbana edited comment on CALCITE-3108 at 6/2/19 12:33 PM:
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented and I prefer that.
I managed to support the TEXT type by adding the type to the root schema:
{code:java}
Connection connection = DriverManager.getConnection("jdbc:calcite:", info);
connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("TEXT",
new RelProtoDataType() {
@Override
public RelDataType apply(RelDataTypeFactory factory) {
return
factory.createTypeWithNullability(factory.createJavaType(String.class), false);
// return
factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
false);
// return factory.createJavaType(String.class); // Failes:
Cannot be nullable
}
});
{code}
And it worked but the returned column type name is {{VARCHAR}}, not {{TEXT}} as
what would be returned form a real PostgreSQL. How could I direct Calcite to
use the type name I provided to the {{.add}} method (ie. {{TEXT}}) instead of
the concluded one (ie. {{VARCHAR}}) ?
was (Author: mgelbana):
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented and I prefer that.
I managed to support the TEXT type by adding the type to the root schema:
{code:java}
Connection connection = DriverManager.getConnection("jdbc:calcite:", info);
connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("TEXT",
new RelProtoDataType() {
@Override
public RelDataType apply(RelDataTypeFactory factory) {
return
factory.createTypeWithNullability(factory.createJavaType(String.class), false);
// return
factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
false);
// return factory.createJavaType(String.class); // Failes:
Cannot be nullable
}
});
{code}
And it worked but the returned column type name is {{VARCHAR}}, not {{TEXT}} as
what would be returned form a real PostgreSQL. How could I direct Calcite to
use the type name I provided to the .add method instead of the concluded one
(ie. {{VARCHAR}}) ?
> Babel parser should parse the PostgreSQL TEXT type
> --
>
> Key: CALCITE-3108
> URL: https://issues.apache.org/jira/browse/CALCITE-3108
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Casting to PostgreSQL TEXT (ie. VARCHAR) isn't currently supported. The
> following query would fail in parsing and execution.
> {code:sql}SELECT CAST(EXPR$0 AS text) FROM (VALUES (1, 2, 3)){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3108) Babel parser should parse the PostgreSQL TEXT type
[
https://issues.apache.org/jira/browse/CALCITE-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853916#comment-16853916
]
Muhammad Gelbana edited comment on CALCITE-3108 at 6/2/19 12:32 PM:
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented and I prefer that.
I managed to support the TEXT type by adding the type to the root schema:
{code:java}
Connection connection = DriverManager.getConnection("jdbc:calcite:", info);
connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("TEXT",
new RelProtoDataType() {
@Override
public RelDataType apply(RelDataTypeFactory factory) {
return
factory.createTypeWithNullability(factory.createJavaType(String.class), false);
// return
factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
false);
// return factory.createJavaType(String.class); // Failes:
Cannot be nullable
}
});
{code}
And it worked but the returned column type name is {{VARCHAR}}, not {{TEXT}} as
what would be returned form a real PostgreSQL. How could I direct Calcite to
use the type name I provided to the .add method instead of the concluded one
(ie. {{VARCHAR}}) ?
was (Author: mgelbana):
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented and I prefer that.
I managed to support the TEXT type by adding the type to the root schema:
{code:java}
Connection connection = DriverManager.getConnection("jdbc:calcite:", info);
connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("TEXT",
new RelProtoDataType() {
@Override
public RelDataType apply(RelDataTypeFactory factory) {
return
factory.createTypeWithNullability(factory.createJavaType(String.class), false);
// return
factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
false);
// return factory.createJavaType(String.class); // Failes:
Cannot be nullable
}
});
{code}
And it worked but the returned column type name is {{VARCHAR}}, not {{TEXT}} as
what would be returned form a real PostgreSQL. How could I direct Calcite to
use the type name I provided to the .add method instead of the concluded one
(ie. {{VARCHAR}}) ?
> Babel parser should parse the PostgreSQL TEXT type
> --
>
> Key: CALCITE-3108
> URL: https://issues.apache.org/jira/browse/CALCITE-3108
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Casting to PostgreSQL TEXT (ie. VARCHAR) isn't currently supported. The
> following query would fail in parsing and execution.
> {code:sql}SELECT CAST(EXPR$0 AS text) FROM (VALUES (1, 2, 3)){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3108) Babel parser should parse the PostgreSQL TEXT type
[
https://issues.apache.org/jira/browse/CALCITE-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853916#comment-16853916
]
Muhammad Gelbana edited comment on CALCITE-3108 at 6/2/19 12:31 PM:
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented and I prefer that.
I managed to support the TEXT type by adding the type to the root schema:
{code:java}
Connection connection = DriverManager.getConnection("jdbc:calcite:", info);
connection.unwrap(CalciteConnection.class).getRootSchema().unwrap(CalciteSchema.class).add("TEXT",
new RelProtoDataType() {
@Override
public RelDataType apply(RelDataTypeFactory factory) {
return
factory.createTypeWithNullability(factory.createJavaType(String.class), false);
// return
factory.createTypeWithNullability(factory.createSqlType(SqlTypeName.VARCHAR),
false);
// return factory.createJavaType(String.class); // Failes:
Cannot be nullable
}
});
{code}
And it worked but the returned column type name is {{VARCHAR}}, not {{TEXT}} as
what would be returned form a real PostgreSQL. How could I direct Calcite to
use the type name I provided to the .add method instead of the concluded one
(ie. {{VARCHAR}}) ?
was (Author: mgelbana):
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented and I prefer that.
I found I can do what you suggested by exposing that type through the exposed
schemas. But I can't find a way to do so for the root schema to get the example
query to work.
> Babel parser should parse the PostgreSQL TEXT type
> --
>
> Key: CALCITE-3108
> URL: https://issues.apache.org/jira/browse/CALCITE-3108
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Casting to PostgreSQL TEXT (ie. VARCHAR) isn't currently supported. The
> following query would fail in parsing and execution.
> {code:sql}SELECT CAST(EXPR$0 AS text) FROM (VALUES (1, 2, 3)){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3108) Babel parser should parse the PostgreSQL TEXT type
[
https://issues.apache.org/jira/browse/CALCITE-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853916#comment-16853916
]
Muhammad Gelbana edited comment on CALCITE-3108 at 6/2/19 10:53 AM:
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented and I prefer that.
I found I can do what you suggested by exposing that type through the exposed
schemas. But I can't find a way to do so for the root schema to get the example
query to work.
was (Author: mgelbana):
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented and I prefer that.
I tried figuring out how can I do what you suggested and I found I can it by
exposing that type through the exposed schemas. But I can't find a way to do so
for the root schema to get the example query to work.
> Babel parser should parse the PostgreSQL TEXT type
> --
>
> Key: CALCITE-3108
> URL: https://issues.apache.org/jira/browse/CALCITE-3108
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Casting to PostgreSQL TEXT (ie. VARCHAR) isn't currently supported. The
> following query would fail in parsing and execution.
> {code:sql}SELECT CAST(EXPR$0 AS text) FROM (VALUES (1, 2, 3)){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3108) Babel parser should parse the PostgreSQL TEXT type
[
https://issues.apache.org/jira/browse/CALCITE-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853916#comment-16853916
]
Muhammad Gelbana edited comment on CALCITE-3108 at 6/2/19 10:12 AM:
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented and I prefer that.
I tried figuring out how can I do what you suggested and I found I can it by
exposing that type through the exposed schemas. But I can't find a way to do so
for the root schema to get the example query to work.
was (Author: mgelbana):
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented, as I'll have to acquire the {{}} and act accordingly. Is
it possible to easily return the column type name as TEXT if I follow that
approach ?
I still have to provide casting rules to support casting types to that
identifier.
> Babel parser should parse the PostgreSQL TEXT type
> --
>
> Key: CALCITE-3108
> URL: https://issues.apache.org/jira/browse/CALCITE-3108
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Casting to PostgreSQL TEXT (ie. VARCHAR) isn't currently supported. The
> following query would fail in parsing and execution.
> {code:sql}SELECT CAST(EXPR$0 AS text) FROM (VALUES (1, 2, 3)){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3065: Attachment: image-2019-06-02-08-43-51-646.png > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png, > image-2019-06-02-08-43-51-646.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853917#comment-16853917 ] Jiatao Tao commented on CALCITE-3065: - !image-2019-06-02-08-43-51-646.png! > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3108) Babel parser should parse the PostgreSQL TEXT type
[
https://issues.apache.org/jira/browse/CALCITE-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853916#comment-16853916
]
Muhammad Gelbana edited comment on CALCITE-3108 at 6/2/19 8:34 AM:
---
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented, as I'll have to acquire the {{}} and act accordingly. Is
it possible to easily return the column type name as TEXT if I follow that
approach ?
I still have to provide casting rules to support casting types to that
identifier.
was (Author: mgelbana):
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented, as I'll have to acquire the {{}} and act accordingly. Is
it possible to easily return the column type name as TEXT if I follow that
approach ?
> Babel parser should parse the PostgreSQL TEXT type
> --
>
> Key: CALCITE-3108
> URL: https://issues.apache.org/jira/browse/CALCITE-3108
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Casting to PostgreSQL TEXT (ie. VARCHAR) isn't currently supported. The
> following query would fail in parsing and execution.
> {code:sql}SELECT CAST(EXPR$0 AS text) FROM (VALUES (1, 2, 3)){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3108) Babel parser should parse the PostgreSQL TEXT type
[
https://issues.apache.org/jira/browse/CALCITE-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853916#comment-16853916
]
Muhammad Gelbana commented on CALCITE-3108:
---
My branches got mixed up and I added this feature to an unmurged PR that
supports the {{::}} operator. Please refer to the description for the updated
sample query.
I added {{TEXT}} as a keyword so the returned result set column type name would
be {{TEXT}} as returned from a PostgreSQL DB.
I don't usually like touching the parser so you're suggestion sounds more Java
oriented, as I'll have to acquire the {{}} and act accordingly. Is
it possible to easily return the column type name as TEXT if I follow that
approach ?
> Babel parser should parse the PostgreSQL TEXT type
> --
>
> Key: CALCITE-3108
> URL: https://issues.apache.org/jira/browse/CALCITE-3108
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Casting to PostgreSQL TEXT (ie. VARCHAR) isn't currently supported. The
> following query would fail in parsing and execution.
> {code:sql}SELECT CAST(EXPR$0 AS text) FROM (VALUES (1, 2, 3)){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3005) Implement string functions: LEFT, RIGHT
[
https://issues.apache.org/jira/browse/CALCITE-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853914#comment-16853914
]
Julian Hyde commented on CALCITE-3005:
--
* A lot of duplication: LEFT and RIGHT functions are virtually identical. I'd
get rid of SqlLeftFunction and SqlRightFunction classes.
* The return type should not be VARCHAR(2000). It should be the same as the
first operand.
* Should LEFT and RIGHT also operate on binary strings?
* Since LEFT and RIGHT have ordinary function syntax, could we just have a
special-case for the function name (allowing LEFT and RIGHT to be converted to
identifier if they occur in a place that a function name could occur), but then
use the usual parsing logic for a function call. In other words, I don't think
LeftFunctionCall() and RightFunctionCall() are necessary. And the parser should
not reference SqlStdOperatorTable.LEFT. Just return an unresolved function call.
> Implement string functions: LEFT, RIGHT
> ---
>
> Key: CALCITE-3005
> URL: https://issues.apache.org/jira/browse/CALCITE-3005
> Project: Calcite
> Issue Type: New Feature
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> Some string functions including LEFT, RIGHT are not implemented now. It would
> be great if these functions can be implemented.
> [{{LEFT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_left]
> Returns the leftmost _{{len}}_ characters from the string _{{str}}_, or
> {{NULL}} if any argument is {{NULL}}.
> [{{RIGHT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_right]
> Returns the rightmost _{{len}}_ characters from the string _{{str}}_, or
> {{NULL}} if any argument is {{NULL}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3108) Babel parser should parse the PostgreSQL TEXT type
[
https://issues.apache.org/jira/browse/CALCITE-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Muhammad Gelbana updated CALCITE-3108:
--
Description:
Casting to PostgreSQL TEXT (ie. VARCHAR) isn't currently supported. The
following query would fail in parsing and execution.
{code:sql}SELECT CAST(EXPR$0 AS text) FROM (VALUES (1, 2, 3)){code}
was:
Casting to PostgreSQL TEXT (ie. VARCHAR) isn't currently supported. The
following query would fail in parsing and execution.
{code:sql}SELECT EXPR$0::text FROM (VALUES (1, 2, 3)){code}
> Babel parser should parse the PostgreSQL TEXT type
> --
>
> Key: CALCITE-3108
> URL: https://issues.apache.org/jira/browse/CALCITE-3108
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
>Affects Versions: 1.19.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Casting to PostgreSQL TEXT (ie. VARCHAR) isn't currently supported. The
> following query would fail in parsing and execution.
> {code:sql}SELECT CAST(EXPR$0 AS text) FROM (VALUES (1, 2, 3)){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853913#comment-16853913 ] Jiatao Tao edited comment on CALCITE-3065 at 6/2/19 8:23 AM: - Hi [~julianhyde] I can buy in your thoughts about null scenario. But the code below, is all Calcite' API, and `tp.getJavaClass(literal.getType)` returns int not Integer(`type.isNullable` return false.). ``` val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType)) ``` !image-2019-06-02-08-15-35-460.png! My point is `JavaTypeFactoryImpl#getJavaClass` may return primitive type(means type is not nullable), shouldn't we consider primitive type in `getValueAs`? Or am I use the API in a wrong way? Hope for your opinion, thanks was (Author: aron.tao): Hi [~julianhyde] I can buy in your thoughts about null scenario. But the code below, is all Calcite' API, and `tp.getJavaClass(literal.getType)` returns int not Integer(`type.isNullable` return false.). val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) !image-2019-06-02-08-15-35-460.png! My point is `JavaTypeFactoryImpl#getJavaClass` may return primitive type(means type is not nullable), shouldn't we consider primitive type in `getValueAs`? Or am I use the API in a wrong way? Hope for your opinion, thanks > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853913#comment-16853913 ] Jiatao Tao edited comment on CALCITE-3065 at 6/2/19 8:20 AM: - Hi [~julianhyde] I can buy in your thoughts about null scenario. But the code below, is all Calcite' API, and `tp.getJavaClass(literal.getType)` returns int not Integer(`type.isNullable` return false.). val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) !image-2019-06-02-08-15-35-460.png! My point is `JavaTypeFactoryImpl#getJavaClass` may return primitive type(means type is not nullable), shouldn't we consider primitive type in `getValueAs`? Or am I use the API in a wrong way? Hope for your opinion, thanks was (Author: aron.tao): Hi [~julianhyde] I can buy in your thoughts about null scenario. But the code below, is all Calcite' API, and `tp.getJavaClass(literal.getType)` returns int not Integer(`type.isNullable` return false.). val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) !image-2019-06-02-08-15-35-460.png! My point is `JavaTypeFactoryImpl#getJavaClass` may return primitive type(means type is not nullable), shouldn't we consider primitive type in `getValueAs`? > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853913#comment-16853913 ] Jiatao Tao commented on CALCITE-3065: - Hi [~julianhyde] I can buy in your thoughts about null scenario. But the code below, is all Calcite' API, and `tp.getJavaClass(literal.getType)` returns int not Integer(`type.isNullable` return false.). val tp = new JavaTypeFactoryImpl(RelDataTypeSystem.DEFAULT) literal.getValueAs(tp.getJavaClass(literal.getType).asInstanceOf[java.lang.Class[_]]) !image-2019-06-02-08-15-35-460.png! My point is `JavaTypeFactoryImpl#getJavaClass` may return primitive type(means type is not nullable), shouldn't we consider primitive type in `getValueAs`? > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[ https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-3065: Attachment: image-2019-06-02-08-15-35-460.png > RexLiteral#getValueAs should consider primitive type > > > Key: CALCITE-3065 > URL: https://issues.apache.org/jira/browse/CALCITE-3065 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Priority: Major > Labels: pull-request-available > Attachments: image-2019-05-13-12-04-36-365.png, > image-2019-05-17-08-23-52-735.png, image-2019-06-02-08-15-35-460.png > > Time Spent: 40m > Remaining Estimate: 0h > > !image-2019-05-13-12-04-36-365.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3005) Implement string functions: LEFT, RIGHT
[
https://issues.apache.org/jira/browse/CALCITE-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853910#comment-16853910
]
Forward Xu commented on CALCITE-3005:
-
hi [~Chunwei Lei] [~julianhyde] Thank you very much, this pr already updated.
> Implement string functions: LEFT, RIGHT
> ---
>
> Key: CALCITE-3005
> URL: https://issues.apache.org/jira/browse/CALCITE-3005
> Project: Calcite
> Issue Type: New Feature
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> Some string functions including LEFT, RIGHT are not implemented now. It would
> be great if these functions can be implemented.
> [{{LEFT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_left]
> Returns the leftmost _{{len}}_ characters from the string _{{str}}_, or
> {{NULL}} if any argument is {{NULL}}.
> [{{RIGHT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_right]
> Returns the rightmost _{{len}}_ characters from the string _{{str}}_, or
> {{NULL}} if any argument is {{NULL}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
