Re: [DISCUSS] Towards Calcite 1.21.0

[Danny Chan]

Let’s get the CALCITE-2302[1]: the full implicit type cast support into 1.21 !

[1] https://github.com/apache/calcite/pull/706

Best,
Danny Chan
在 2019年7月21日 +0800 PM3:28，Stamatis Zampetakis ，写道：
> Hi all,
>
> Approximately one month has passed from the previous release (Calcite
> 1.20.0) and I was thinking that it would be nice to have the next release
> out by the end of August. To do this I think we should try to have an RC
> around the 20 of August.
>
> The progress towards the next release can be seen in [1]. As you can
> observe we do not have many issues marked for fixing for 1.21.0 but we do
> have many pull requests.
>
> I would like to invite committers to go over the existing PRs and for those
> that we plan to review and finalize in the next month or so set the fix
> version to 1.21.0 adding an appropriate comment.
>
> In term of priorities, I think we should emphasize on finalizing and
> merging PRs that are blocking other open source projects and commercial
> products from upgrading to the latest release. If it is not already done
> please assign this issues the highest priority (blocker) and set the fix
> version to 1.21.0.
>
> Apart from very important issues it makes sense to treat PRs in FIFO order.
> Contributors who submit a PR early will certainly get discouraged to
> contribute again if we never merge these PRs in time.
>
> Don't hesitate to reply to this thread if the plan above is not convenient
> for you!
>
> Best,
> Stamatis
>
> [1]
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950

AW: [DISCUSS] Towards Calcite 1.21.0

[Julian Feinauer]

Hi Stamatis,

Thank you for the overview.
Currently Julian is working on a Pr of mine which does not exactly fix 
CALCITE-1935 but at least bring in the first support for MATCH_RECOGNIZE which 
I would consider at list a partial success.

But as the PR is rather big and the branch lived for two years Julian had to 
comment whether he thinks he can manage it.

Best
JulianF

Von meinem Mobiltelefon gesendet


 Ursprüngliche Nachricht 
Betreff: Re: [DISCUSS] Towards Calcite 1.21.0
Von: Chunwei Lei
An: dev@calcite.apache.org
Cc:

Thanks for your work, Stamatis!

Besides issues you mentioned above, I wonder if CALCITE-1581
 can be included in
1.21.0.


Best,
Chunwei


On Thu, Aug 1, 2019 at 6:29 AM Stamatis Zampetakis 
wrote:

> We are about three weeks before RC0 and we still have a big number of
> pending PRs.
> Moreover there are only a few Jira cases that are marked to be fixed in
> 1.21.0.
>
> If we assume that we have 10 active committers at the moment and each one
> of them takes on ~5 PRs till the 20th of August,
> we should have at least 50 Jiras marked to be resolved for the next
> version.
>
> I would like to kindly ask people to go through the PRs, select those that
> are going to make it for 1.21.0, and set the fix version accordingly.
>
> At the moment we have resolved 46 issues in Jira [1]. It would be great if
> we could bring this number to 50 by 7th of August.
>
> I've seen that Enrico started another thread about regressions on 1.20.0.
> Let's try to attack this issues first to allow people upgrade to the latest
> release.
>
> Among the issues that we would like to include in 1.21.0, I would like to
> highlight the following:
>
> https://issues.apache.org/jira/browse/CALCITE-2302
> https://issues.apache.org/jira/browse/CALCITE-3122
> https://issues.apache.org/jira/browse/CALCITE-3142
>
> Best,
> Stamatis
>
> [1]
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
>
> On Mon, Jul 22, 2019 at 1:56 PM Chunwei Lei 
> wrote:
>
> > +1 for release at end of August.
> >
> > > Apart from very important issues it makes sense to treat PRs in FIFO
> > order.
> > Contributors who submit a PR early will certainly get discouraged to
> > contribute again if we never merge these PRs in time.
> >
> > +1 since it is very important for encouraging contributors.
> >
> >
> >
> > Best,
> > Chunwei
> >
> >
> > On Mon, Jul 22, 2019 at 9:19 AM Danny Chan  wrote:
> >
> > > >Apart from very important issues it makes sense to treat PRs in FIFO
> > > order.
> > > Contributors who submit a PR early will certainly get discouraged to
> > > contribute again if we never merge these PRs in time.
> > >
> > > There are 110+ PRs on the GitHub page, what should we do ?
> > >
> > > Best,
> > > Danny Chan
> > > 在 2019年7月22日 +0800 AM6:19，dev@calcite.apache.org，写道：
> > > >
> > > > Apart from very important issues it makes sense to treat PRs in FIFO
> > > order.
> > > > Contributors who submit a PR early will certainly get discouraged to
> > > > contribute again if we never merge these PRs in time.
> > >
> >
>

[jira] [Created] (CALCITE-3223) Non-RexInputRef may fails the matching of FilterToProjectUnifyRule during 'invert' by mistake.

[jin xing (JIRA)]

jin xing created CALCITE-3223:
-

 Summary: Non-RexInputRef may fails the matching of 
FilterToProjectUnifyRule during 'invert' by mistake.
 Key: CALCITE-3223
 URL: https://issues.apache.org/jira/browse/CALCITE-3223
 Project: Calcite
  Issue Type: Bug
  Components: core
Reporter: jin xing


In current code of 
{{FilterToProjectUnifyRule::invert}}(https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/SubstitutionVisitor.java#L1124),
  the implementation 
1. Fails the matching when there is Non-RexInputRef  in the projects
2. Didn't check if all {{exprList}} has already ben set correctly.
As a result below tests  fails.

{code:java}
  @Test public void testFilterToProject0() {
String union =
"select * from \"emps\" where \"empid\" > 300\n"
+ "union all select * from \"emps\" where \"empid\" < 200";
String mv = "select *, \"empid\" * 2 from (" + union + ")";
String query = "select * from (" + union + ") where (\"empid\" * 2) > 3";
checkMaterialize(mv, query);
  }

  @Test public void testFilterToProject1() {
String agg =
"select \"deptno\", count(*) as \"c\", sum(\"salary\") as \"s\"\n"
+ "from \"emps\" group by \"deptno\"";
String mv = "select \"c\", \"s\", \"s\" from (" + agg + ")";
String query = "select * from (" + agg + ") where (\"s\" * 0.8) > 1";
checkNoMaterialize(mv, query, HR_FKUK_MODEL);
  }
{code}




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: Calcite at ApacheCon NA

[Chunwei Lei]

Excellent! I am looking forward to these presentations.

By the way, can we watch this conference via live network?


Best,
Chunwei


On Thu, Aug 1, 2019 at 5:49 AM Stamatis Zampetakis 
wrote:

> With so many interesting presentations involving Calcite, I'm really sorry
> that I am going to miss this event.
>
> I've seen that the presentations from last year can be found in youtube.
> Hope it is the case for this year too!
>
> Stamatis
>
> On Tue, Jul 30, 2019 at 3:58 PM Michael Mior  wrote:
>
> > That's excellent! Unfortunately with my teaching responsibilities, I
> > won't be able to attend, but it's wonderful to see this
> > representation.
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le lun. 29 juil. 2019 à 20:22, Julian Hyde  a écrit :
> > >
> > > ApacheCon North America is in Las Vegas 8 - 12 September. There are 5
> > talks about Calcite [1].
> > >
> > > Yes, five! A great indication that Calcite is being widely used. (Of
> > those 5 talks, 3 also cover Beam, 2 cover Flink, and one each MaxCompute,
> > Drill and Samza.)
> > >
> > > Consider coming along. It’s a great opportunity to meet fellow members
> > of the Apache community. There is a discount off of the conference fee if
> > you are a committer or in academia, and I believe travel assistance
> grants
> > are still available.
> > >
> > > I am giving one of the talks. I’m looking forward to meeting the other
> > speakers (Haisheng Yuan, Aman Sinha, Andrew Pilloud, Kenneth Knowles,
> Khai
> > Tran), most of whom I have only met over email.
> > >
> > > Julian
> > >
> > > [1]
> https://apachecon.com/acna19/s/#/schedule/2019-09-12?search=calcite
> > 
> > >
> >
>

Re: [DISCUSS] Towards Calcite 1.21.0

[Chunwei Lei]

Thanks for your work, Stamatis!

Besides issues you mentioned above, I wonder if CALCITE-1581
 can be included in
1.21.0.


Best,
Chunwei


On Thu, Aug 1, 2019 at 6:29 AM Stamatis Zampetakis 
wrote:

> We are about three weeks before RC0 and we still have a big number of
> pending PRs.
> Moreover there are only a few Jira cases that are marked to be fixed in
> 1.21.0.
>
> If we assume that we have 10 active committers at the moment and each one
> of them takes on ~5 PRs till the 20th of August,
> we should have at least 50 Jiras marked to be resolved for the next
> version.
>
> I would like to kindly ask people to go through the PRs, select those that
> are going to make it for 1.21.0, and set the fix version accordingly.
>
> At the moment we have resolved 46 issues in Jira [1]. It would be great if
> we could bring this number to 50 by 7th of August.
>
> I've seen that Enrico started another thread about regressions on 1.20.0.
> Let's try to attack this issues first to allow people upgrade to the latest
> release.
>
> Among the issues that we would like to include in 1.21.0, I would like to
> highlight the following:
>
> https://issues.apache.org/jira/browse/CALCITE-2302
> https://issues.apache.org/jira/browse/CALCITE-3122
> https://issues.apache.org/jira/browse/CALCITE-3142
>
> Best,
> Stamatis
>
> [1]
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
>
> On Mon, Jul 22, 2019 at 1:56 PM Chunwei Lei 
> wrote:
>
> > +1 for release at end of August.
> >
> > > Apart from very important issues it makes sense to treat PRs in FIFO
> > order.
> > Contributors who submit a PR early will certainly get discouraged to
> > contribute again if we never merge these PRs in time.
> >
> > +1 since it is very important for encouraging contributors.
> >
> >
> >
> > Best,
> > Chunwei
> >
> >
> > On Mon, Jul 22, 2019 at 9:19 AM Danny Chan  wrote:
> >
> > > >Apart from very important issues it makes sense to treat PRs in FIFO
> > > order.
> > > Contributors who submit a PR early will certainly get discouraged to
> > > contribute again if we never merge these PRs in time.
> > >
> > > There are 110+ PRs on the GitHub page, what should we do ?
> > >
> > > Best,
> > > Danny Chan
> > > 在 2019年7月22日 +0800 AM6:19，dev@calcite.apache.org，写道：
> > > >
> > > > Apart from very important issues it makes sense to treat PRs in FIFO
> > > order.
> > > > Contributors who submit a PR early will certainly get discouraged to
> > > > contribute again if we never merge these PRs in time.
> > >
> >
>

Re: How to execute an SQL query without using Calcite's JDBC API ?

[Stamatis Zampetakis]

Hi Gelbana,

I guess you can derive the correct type by looking in the RelDataType of
the plan.
The method JavaTypeFactory#getJavaClass might be of some help there.

Otherwise you can use an Iterator as it is for instance in
AvaticaResultSet [1].

Best,
Stamatis

[1]
https://github.com/apache/calcite-avatica/blob/8138d42841a599397fa6bedcb53ae694d388f100/core/src/main/java/org/apache/calcite/avatica/AvaticaResultSet.java#L181

On Mon, Jul 29, 2019 at 3:28 PM Muhammad Gelbana 
wrote:

> Thanks a lot Stamatis, very helpful and responsive as always :)
>
> Here is what worked perfectly for me so far after building over what you
> provided.
>
> HashMap parameters = new HashMap<>();
> dataContext.setMap(parameters); // A custom context object holding my root
> schema and type factory. The setMap method is custom too to provide my own
> parameters map
> Iterator resultsIterator =
> EnumerableInterpretable.toBindable(parameters, null, (EnumerableRel)
> planned, EnumerableRel.Prefer.ARRAY).bind(dataContext).iterator();
> // "planned" is the optimized/physical plan.
>
> Now the "resultsIterator" iterator has all my result set. The tricky part
> was that for single column resultsets, the output from the iterator is a
> single object, not an Object[].
>
> Thanks,
> Gelbana
>
>
> On Wed, Jul 17, 2019 at 11:31 PM Stamatis Zampetakis 
> wrote:
>
> > Hi Gelbana,
> >
> > In [1, 2] you can find rather full end-to-end example with the main
> Calcite
> > primitives in use. Hope it helps!
> >
> > Best,
> > Stamatis
> >
> > [1]
> >
> >
> https://github.com/zabetak/calcite/blob/livecodingdemo/core/src/test/java/org/apache/calcite/examples/foodmart/java/EndToEndExampleBindable.java
> > [2]
> >
> >
> https://github.com/michaelmior/calcite-notebooks/blob/master/query-optimization.ipynb
> >
> > On Wed, Jul 17, 2019 at 7:18 PM Muhammad Gelbana 
> > wrote:
> >
> > > I think I saw a message asking the same thing but I'm unable to dig it
> up
> > > as I can't quite remember the subject. Is there a test class that
> > executes
> > > SQL queries and access the results without using the JDBC API ?
> > >
> > > Here is my attempt:
> > > ---
> > > Planner planner = Frameworks.getPlanner(frameworkConfig); //
> > > frameworkConfig programs is set usign "Programs.standard()"
> > >
> > > SqlNode parsed = planner.parse("SELECT 1 + 1 FROM myschema.mytable
> limit
> > 1"
> > > ); // Assume the existense of "myschema.mytable", don't try (VALUES())
> > > SqlNode validated = planner.validate(parsed);
> > > RelNode converted = planner.rel(validated).rel;
> > > RelNode planned = planner.transform(0,
> > > converted.getTraitSet().replace(EnumerableConvention.INSTANCE),
> > converted);
> > >
> > > TestDataContext dataContext = new TestDataContext(rootSchema,
> > > (JavaTypeFactory) planner.getTypeFactory()); // A context that provides
> > the
> > > root schema and the java type factory only
> > > try (Interpreter interpreter = new Interpreter(dataContext, planned)) {
> > > Enumerator results =
> > interpreter.asEnumerable().enumerator();
> > > while(results.moveNext()) {
> > > System.out.println(Arrays.toString(results.current()));
> > > }
> > > }
> > > ---
> > > This fails and throws the following error
> > > Exception in thread "main" java.lang.AssertionError: interpreter: no
> > > implementation for class
> > > org.apache.calcite.adapter.enumerable.EnumerableInterpreter
> > > at
> > >
> > >
> >
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:460)
> > > at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:42)
> > > at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> > > at
> > >
> > >
> >
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:447)
> > > at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:42)
> > > at
> > >
> > >
> >
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:405)
> > > at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:88)
> > >
> > > The output of RelOptUtil.toString(planned) is
> > > EnumerableCalc(expr#0..22=[{inputs}], expr#23=[1], expr#24=[2],
> > > expr#25=[+($t23, $t24)], EXPR$0=[$t25])
> > >   EnumerableLimit(fetch=[1])
> > > EnumerableInterpreter
> > >   BindableTableScan(table=[[myschema, mytable]])
> > >
> > > The reason for this is the converter node "EnumerableInterpreter"
> > > converting from the bindable table scan node to an enumerable
> convention
> > > node.
> > >
> > > Thanks,
> > > Gelbana
> > >
> >
>

Re: [DISCUSS] Towards Calcite 1.21.0

[Stamatis Zampetakis]

We are about three weeks before RC0 and we still have a big number of
pending PRs.
Moreover there are only a few Jira cases that are marked to be fixed in
1.21.0.

If we assume that we have 10 active committers at the moment and each one
of them takes on ~5 PRs till the 20th of August,
we should have at least 50 Jiras marked to be resolved for the next version.

I would like to kindly ask people to go through the PRs, select those that
are going to make it for 1.21.0, and set the fix version accordingly.

At the moment we have resolved 46 issues in Jira [1]. It would be great if
we could bring this number to 50 by 7th of August.

I've seen that Enrico started another thread about regressions on 1.20.0.
Let's try to attack this issues first to allow people upgrade to the latest
release.

Among the issues that we would like to include in 1.21.0, I would like to
highlight the following:

https://issues.apache.org/jira/browse/CALCITE-2302
https://issues.apache.org/jira/browse/CALCITE-3122
https://issues.apache.org/jira/browse/CALCITE-3142

Best,
Stamatis

[1]
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950

On Mon, Jul 22, 2019 at 1:56 PM Chunwei Lei  wrote:

> +1 for release at end of August.
>
> > Apart from very important issues it makes sense to treat PRs in FIFO
> order.
> Contributors who submit a PR early will certainly get discouraged to
> contribute again if we never merge these PRs in time.
>
> +1 since it is very important for encouraging contributors.
>
>
>
> Best,
> Chunwei
>
>
> On Mon, Jul 22, 2019 at 9:19 AM Danny Chan  wrote:
>
> > >Apart from very important issues it makes sense to treat PRs in FIFO
> > order.
> > Contributors who submit a PR early will certainly get discouraged to
> > contribute again if we never merge these PRs in time.
> >
> > There are 110+ PRs on the GitHub page, what should we do ?
> >
> > Best,
> > Danny Chan
> > 在 2019年7月22日 +0800 AM6:19，dev@calcite.apache.org，写道：
> > >
> > > Apart from very important issues it makes sense to treat PRs in FIFO
> > order.
> > > Contributors who submit a PR early will certainly get discouraged to
> > > contribute again if we never merge these PRs in time.
> >
>

Re: Calcite at ApacheCon NA

[Stamatis Zampetakis]

With so many interesting presentations involving Calcite, I'm really sorry
that I am going to miss this event.

I've seen that the presentations from last year can be found in youtube.
Hope it is the case for this year too!

Stamatis

On Tue, Jul 30, 2019 at 3:58 PM Michael Mior  wrote:

> That's excellent! Unfortunately with my teaching responsibilities, I
> won't be able to attend, but it's wonderful to see this
> representation.
> --
> Michael Mior
> mm...@apache.org
>
> Le lun. 29 juil. 2019 à 20:22, Julian Hyde  a écrit :
> >
> > ApacheCon North America is in Las Vegas 8 - 12 September. There are 5
> talks about Calcite [1].
> >
> > Yes, five! A great indication that Calcite is being widely used. (Of
> those 5 talks, 3 also cover Beam, 2 cover Flink, and one each MaxCompute,
> Drill and Samza.)
> >
> > Consider coming along. It’s a great opportunity to meet fellow members
> of the Apache community. There is a discount off of the conference fee if
> you are a committer or in academia, and I believe travel assistance grants
> are still available.
> >
> > I am giving one of the talks. I’m looking forward to meeting the other
> speakers (Haisheng Yuan, Aman Sinha, Andrew Pilloud, Kenneth Knowles, Khai
> Tran), most of whom I have only met over email.
> >
> > Julian
> >
> > [1] https://apachecon.com/acna19/s/#/schedule/2019-09-12?search=calcite
> 
> >
>

[jira] [Created] (CALCITE-3222) Fix code style issues introduced by CALCITE-3031

[Vineet Garg (JIRA)]

Vineet Garg created CALCITE-3222:


 Summary: Fix code style issues introduced by CALCITE-3031
 Key: CALCITE-3222
 URL: https://issues.apache.org/jira/browse/CALCITE-3222
 Project: Calcite
  Issue Type: Task
Reporter: Vineet Garg
Assignee: Vineet Garg






--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (CALCITE-3221) Add a sort-merge union algorithm

[Stamatis Zampetakis (JIRA)]

Stamatis Zampetakis created CALCITE-3221:


 Summary: Add a sort-merge union algorithm
 Key: CALCITE-3221
 URL: https://issues.apache.org/jira/browse/CALCITE-3221
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.19.0
Reporter: Stamatis Zampetakis
Assignee: Stamatis Zampetakis


Currently, the union operation offered by Calcite is based on a {{HashSet}} 
(see 
[EnumerableDefaults.union|https://github.com/apache/calcite/blob/d98856bf1a5f5c151d004b769e14bdd368a67234/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L2747])
 and necessitates reading in memory all rows before returning a single result.  
 

Apart from increased memory consumption the operator is blocking and also 
destroys the order of its inputs.  

The goal of this issue is to add a new union algorithm (EnumerableMergeUnion ?) 
exploiting the fact that the inputs are sorted which consumes less memory and 
retains the order of its inputs.   

Most likely the implementation of the merge join can be useful.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Problems with Subqueries and simple aggregations on Calcite 1.20

[Enrico Olivelli]

Hello,
We are upgrading HerdDB from Calcite 1.19 to 1.20 but we are falling into
serious issues regarding subqueries and aggregations on very simple queries.

I am really sorry I did not have time to test 1.20 before the release this
time.

I will create JIRAs but maybe someone has already an idea of which change
could have broken these cases.

HerdDB is only using Calcite planner, just by configuring it with only
standard rules (no custom rules, no custom traits/convensions, only
EnumerableConvention), basic configuration and an implementation of the
Schema of the tables.


Problem 1: SELECT MIN(n1) as mi, MAX(n1) as ma FROM tblspace1.tsql

Result:

java.lang.IllegalArgumentException: source #1 is already mapped to target #1
at 
org.apache.calcite.util.mapping.Mappings$SurjectionWithInverse.set(Mappings.java:1326)
at org.apache.calcite.rel.core.Project.getMapping(Project.java:279)
at org.apache.calcite.rel.core.Project.getMapping(Project.java:250)
at 
org.apache.calcite.rel.rules.ProjectTableScanRule.apply(ProjectTableScanRule.java:107)
at 
org.apache.calcite.rel.rules.ProjectTableScanRule$2.onMatch(ProjectTableScanRule.java:83)
at 
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
... 30 more



Problem 2 (subquery in DML) : UPDATE tblspace1.table1 set n1=1000 WHERE k1
in (SELECT fk FROM tblspace1.table2 WHERE k2=?)


class org.apache.calcite.sql.SqlBasicCall: `K1` IN (SELECT `table2`.`fk` AS `FK`
FROM `tblspace1`.`table2` AS `TABLE2`
WHERE `table2`.`k2` = ?)
at org.apache.calcite.util.Util.needToImplement(Util.java:967)
at 
org.apache.calcite.sql.validate.SqlValidatorImpl.getValidatedNodeType(SqlValidatorImpl.java:1579)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.findSubQueries(SqlToRelConverter.java:1802)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.findSubQueries(SqlToRelConverter.java:1776)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.replaceSubQueries(SqlToRelConverter.java:1011)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3570)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3172)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563)
at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:254)
at herddb.sql.CalcitePlanner.runPlanner(CalcitePlanner.java:506)
at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:293)
at herddb.core.TestUtils.executeUpdate(TestUtils.java:43)


You can find the details in this PR
https://github.com/diennea/herddb/pull/404

Thank you in advance
Enrico

[jira] [Created] (CALCITE-3220) HiveSqlDialect transform function trim to correct hive format

[Jacky Woo (JIRA)]

Jacky Woo created CALCITE-3220:
--

 Summary: HiveSqlDialect transform function trim to correct hive 
format
 Key: CALCITE-3220
 URL: https://issues.apache.org/jira/browse/CALCITE-3220
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.19.0
Reporter: Jacky Woo


Let's assume sql = SELECT TRIM(' str ')

When we use HiveSqlDialect and transform "sql", we expect SELECT TRIM(' str 
')，but get SELECT TRIM(BOTH ' ' FROM ' str ') which is incorrect  sql format in 
hive.

So maybe HiveSqlDialect behavior should be changed when transform function trim:
 # {{SELECT TRIM(' str ')  =>  SELECT TRIM(' str ') }}
 # {{SELECT TRIM(BOTH ' ' from ' str ') => SELECT TRIM(' str ')}}
 # {{SELECT TRIM(LEADING ' ' from ' str ') => SELECT LTRIM(' str ')}}
 # {{SELECT TRIM(TRAILING ' ' from ' str ')=>  SELECT RTRIM(' str ') }}

{{This is the linked github pr #1342}}

 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Calcite-Master - Build # 1276 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #1276)

Status: Failure

Check console output at https://builds.apache.org/job/Calcite-Master/1276/ to 
view the results.