Re: [DISCUSS] Remove Kotlin

[Vladimir Sitnikov]

Julian>actions over the last few weeks have left me angry, depressed, and
burned out with the project

That is sad. Please accept my apologies for hurting your feelings.

Julian>Of course, a lot of the things he is removing are things that I
personally have created, so I naturally take this more personally than most
people

I did not even think about targeting someone specific.
The tools like Maven and Checkstyle were great 10 years ago, however, the
tools are lagging behind up to the point they severely impact
developer experience.

I can elaborate, but take "the order of the imports" issue for example.
Checkstyle produces errors, however, they are really hard to understand,
especially for new contributors.
On top of that, it turned out, Checkstyle accepted slight variations of the
import order, thus our codebase was using different imports at the same
time.

I replaced Checkstyle with Spotless, so the import order violations are now
printed in a human-readable format, and imports can be adjusted
automatically.
On top of that, I added .editorconfig, so the order of the imports is
automatically configured in IDEA.

Does that mean I removed Checkstyle configuration for import order? It does.
Did I remove Julian's code? Probably I did. I did not investigate who
created the import order configuration before.

Julian>We should go back to being solely Java.

Does that imply we remove Quidem, Cassandra, Druid, ElasitcSearch, Geode,
Kafka, MongoDB, Pig, Piglet, Spark and Splunk languages as well?
All of the above are non-Java languages, so if you suggest being "solely
Java", that should imply we treat the above as languages as well.

Julian>The general reaction was against the idea[1].

The general reaction was for "tests with $" and for "converting all the
things".
$ is important in that discussion.

Julian>After receiving this feedback, he went ahead anyway[2].

Julian, I'm afraid you are overreacting. [1] and [2] are not related.

Did I convert the test that was discussed in [1]?
Of course, I did not.

Did I convert all the uses of $ to something else?
Of course, I did not.

Did I convert ANY test with $?
Of course, I did not.

Did I convert a test in [2]?
Yes, I did. The converted test has absolutely nothing complicated, and its
readability much improved.

Note: I had received positive feedback on similar changes:
https://lists.apache.org/thread.html/5510cb6a825452d2b79600d4293c0ce487932ed51b1e22a3003452f7%40%3Ccommits.calcite.apache.org%3E
so

The old Java source in [2] missed \n characters in certain lines:
https://github.com/apache/calcite/commit/b93ec5a9edb7459696385e6adad67b92b6d406d7#diff-97678cea1fb54ed4236764d6a492e386L151-L152
It was absolutely not visible in the Java sources, and now the formatting
is much easier to follow.

Vladimir

Re: Problems to validate ddl commands

[XING JIN]

Hi Anthony ~
Calcite supports to validate DDL;
I cannot open your link, would you please give some details for your
problem ?

Best,
Jin

Anthony Louis  于2019年12月17日周二
上午4:08写道：

> When I try to validate a sql statement that contains "CREATE TABLE" it
> throws an error that is described in this gist
> https://gist.github.com/anthonylouisbsb/5f7d57886836cfac1742366722afcf41.
> I
> would like to know if is possible to validate a query using ddl statements?
>

Re: Contribute to Calcite

[Francis Chuang]

Hey Shuo,

I've added you as a contributor in Jira.

Francis

On 17/12/2019 3:13 pm, Shuo Cheng wrote:

Hi Guys,

I want to contribute to Apache Calcite.
Would you please give me the permission as a contributor?
My JIRA ID is icshuo.

Contribute to Calcite

[Shuo Cheng]

Hi Guys,

I want to contribute to Apache Calcite.
Would you please give me the permission as a contributor?
My JIRA ID is icshuo.

Re: [VOTE] Release apache-calcite-avatica-1.16.0 (release candidate 1)

[Rui Wang]

Mac OS 10.15.2, jdk 1.8.0_181, Gradle 6.0.1

- checked that the git tag has the right commit.
- run "./gradlew build -PskipSigning" in git repo successfully.
- run "./gradlew clean build" in staged sources successfully.
- verified the sha512 hash of apache-calcite-avatica-1.16.0-src.tar.gz by
running "shasum -a512 apache-calcite-avatica-1.16.0-src.tar.gz"
- checked staged Maven repository which looks good.
- found the diff related to LICENSE and licenses/ and it's discussed above.


Release notes contain more commits without Jira links compared to past
several releases. Read those commits and seems like they are related to
gradle migration/style fixes.


+1 (non-binding)


-Rui

On Wed, Dec 11, 2019 at 2:20 PM Francis Chuang 
wrote:

> Hi all,
>
> I have created a build for Apache Calcite Avatica 1.16.0, release
> candidate 1.
>
> Thanks to everyone who has contributed to this release.
>
> You can read the release notes here:
>
> https://github.com/apache/calcite-avatica/blob/512bbee4aa24ef9fb8106d0286d1243679dce2d0/site/_docs/history.md
>
> The commit to be voted upon:
>
> https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=512bbee4aa24ef9fb8106d0286d1243679dce2d0
>
> Its hash is 512bbee4aa24ef9fb8106d0286d1243679dce2d0
>
> Tag:
>
> https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=tag;h=refs/tags/avatica-1.16.0-rc1
>
> The artifacts to be voted on are located here:
>
> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.16.0-rc1
> (revision 37181)
>
> The hashes of the artifacts are as follows:
>
> 102d3ab0e90dd1db5e012a966d265bdfa8a0f24f9016a4187a6e5f0135a14770da124493dd2c7a18c9d8d8b9af5ecf4f5aceb90d48421251f38bc6ce6f5be697
> *apache-calcite-avatica-1.16.0-src.tar.gz
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/content/repositories/orgapachecalcite-1071/org/apache/calcite/
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/francischuang.asc
> https://www.apache.org/dist/calcite/KEYS
>
> N.B.
> To create the jars and test Apache Calcite Avatica: "./gradlew build
> -PskipSigning".
>
> If you do not have a Java environment available, you can run the tests
> using docker. To do so, install docker and docker-compose, then run
> "docker-compose run test" from the root of the directory.
>
> Please vote on releasing this package as Apache Calcite Avatica 1.16.0.
>
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Calcite 1.16.0
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
>
>
> Here is my vote:
>
> +1 (binding)
>
> Francis
>

Re: [DISCUSS] Remove Kotlin

[Chunwei Lei]

As far as I can see, introducing Kotlin does not have remarkable benefits.
Furthermore, it
brings some extra burdens. So I am +1 for removing Kotlin.



Best,
Chunwei


On Tue, Dec 17, 2019 at 8:38 AM Kevin Risden  wrote:

> Focusing on the technical side of things, I agree that introducing a new
> language is of little benefit currently. I am not paying super close
> attention to the commits lately and am surprised that a change went in to
> switch to Kotlin especially after the discussion that is happening on the
> mailing list.
>
> When Kotlin was originally proposed it was also not a clear cut favorite
> [1]. Since it still seems to be causing angst, I am in favor of removing
> Kotlin altogether.  In my opinion there are more negatives than positives
> currently.
>
> This is not to exclude the idea of moving to Kotlin at some point in the
> future, but the support is not there right now to keep including Kotlin.
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/calcite-dev/201809.mbox/%3cCAB=Je-F8BVTufLGBDTyX0fHQ=fd8ex8dr+8rlqt4fqm8jr0...@mail.gmail.com%3e
>
> Kevin Risden
>
>
> On Mon, Dec 16, 2019 at 3:44 PM Julian Hyde  wrote:
>
> > Vladimir proposed that we convert some tests to Kotlin. The general
> > reaction was against the idea[1]. After receiving this feedback, he went
> > ahead anyway[2].
> >
> > I propose that we remove all Kotlin from our source code, including
> tests.
> > The benefits of being a hybrid Java+Kotlin project do not outweigh the
> > negatives. We should go back to being solely Java. (I would make an
> > exception for build.gradle.kts, because build scripts are generally in a
> > different language.)
> >
> > Vladimir clearly has a lot of enthusiasm to change the build system,
> > coding style, the languages we use. I tend to be more conservative (don’t
> > fix things that aren’t broken). Speaking personally, I find working with
> > Vladimir extremely stressful. Of course, a lot of the things he is
> removing
> > are things that I personally have created, so I naturally take this more
> > personally than most people. Still, his actions over the last few weeks
> > have left me angry, depressed, and burned out with the project.
> >
> > Julian
> >
> > [1]
> >
> https://lists.apache.org/thread.html/c95bc24a10952ccaaa8ac1f959bf65aec450b8bf2fa36ba99dd0df08%40%3Cdev.calcite.apache.org%3E
> > <
> >
> https://lists.apache.org/thread.html/c95bc24a10952ccaaa8ac1f959bf65aec450b8bf2fa36ba99dd0df08@%3Cdev.calcite.apache.org%3E
> > >
> >
> > [2]
> >
> https://github.com/apache/calcite/commit/b93ec5a9edb7459696385e6adad67b92b6d406d7
> > <
> >
> https://github.com/apache/calcite/commit/b93ec5a9edb7459696385e6adad67b92b6d406d7
> > >
> >
> >
> >
>

Re: [DISCUSS] Remove Kotlin

[Kevin Risden]

Focusing on the technical side of things, I agree that introducing a new
language is of little benefit currently. I am not paying super close
attention to the commits lately and am surprised that a change went in to
switch to Kotlin especially after the discussion that is happening on the
mailing list.

When Kotlin was originally proposed it was also not a clear cut favorite
[1]. Since it still seems to be causing angst, I am in favor of removing
Kotlin altogether.  In my opinion there are more negatives than positives
currently.

This is not to exclude the idea of moving to Kotlin at some point in the
future, but the support is not there right now to keep including Kotlin.

[1]
http://mail-archives.apache.org/mod_mbox/calcite-dev/201809.mbox/%3cCAB=Je-F8BVTufLGBDTyX0fHQ=fd8ex8dr+8rlqt4fqm8jr0...@mail.gmail.com%3e

Kevin Risden


On Mon, Dec 16, 2019 at 3:44 PM Julian Hyde  wrote:

> Vladimir proposed that we convert some tests to Kotlin. The general
> reaction was against the idea[1]. After receiving this feedback, he went
> ahead anyway[2].
>
> I propose that we remove all Kotlin from our source code, including tests.
> The benefits of being a hybrid Java+Kotlin project do not outweigh the
> negatives. We should go back to being solely Java. (I would make an
> exception for build.gradle.kts, because build scripts are generally in a
> different language.)
>
> Vladimir clearly has a lot of enthusiasm to change the build system,
> coding style, the languages we use. I tend to be more conservative (don’t
> fix things that aren’t broken). Speaking personally, I find working with
> Vladimir extremely stressful. Of course, a lot of the things he is removing
> are things that I personally have created, so I naturally take this more
> personally than most people. Still, his actions over the last few weeks
> have left me angry, depressed, and burned out with the project.
>
> Julian
>
> [1]
> https://lists.apache.org/thread.html/c95bc24a10952ccaaa8ac1f959bf65aec450b8bf2fa36ba99dd0df08%40%3Cdev.calcite.apache.org%3E
> <
> https://lists.apache.org/thread.html/c95bc24a10952ccaaa8ac1f959bf65aec450b8bf2fa36ba99dd0df08@%3Cdev.calcite.apache.org%3E
> >
>
> [2]
> https://github.com/apache/calcite/commit/b93ec5a9edb7459696385e6adad67b92b6d406d7
> <
> https://github.com/apache/calcite/commit/b93ec5a9edb7459696385e6adad67b92b6d406d7
> >
>
>
>

Re: [DISCUSS] Tests vs multiline strings

[Kevin Risden]

I don't see a major benefit to switching to an entirely new language to get
multiline strings. I agree that sticking to Java makes sense.

Kevin Risden


On Mon, Dec 16, 2019 at 12:50 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Feng>Introducing another language
>
> It is the same language that is used for the build scripts, so it is not a
> new language.
>
> Danny> in the code evolving and the Scala has many
> Danny> tricky problems especially the version compatibility
>
> Kotlin has strong backward compatibility.
>
> Julian>Transitioning our tests to a different language (Kotlin) is a
> Julian> drastic solution. It requires developers to understand a new
> language,
>
> Note: most of the time, test code is just a glue code between input data
> and asserts. The complicated logic is not there (which is good by the way).
>
> At the same time, it means it will be very little new to understand.
>
> Vladimir
>

Re: [VOTE] Release apache-calcite-avatica-1.16.0 (release candidate 1)

[Kevin Risden]

+1 (binding)

* Check signatures and hashes
* Checked src matches git hash - same comment about licenses as Stamtis
* Checked build ran for git hash and src tar.gz
* Checked Maven repo looks complete
* Same comment as Stamatis about release notes being a bit rough to follow
w/ all the commits.

Kevin Risden


On Mon, Dec 16, 2019 at 4:07 PM Francis Chuang 
wrote:

> Hey everyone,
>
> Just a quick reminder that the vote for Avatica 1.16.0 rc1 is still open.
>
> Francis
>
> On 12/12/2019 9:20 am, Francis Chuang wrote:
> > Hi all,
> >
> > I have created a build for Apache Calcite Avatica 1.16.0, release
> > candidate 1.
> >
> > Thanks to everyone who has contributed to this release.
> >
> > You can read the release notes here:
> >
> https://github.com/apache/calcite-avatica/blob/512bbee4aa24ef9fb8106d0286d1243679dce2d0/site/_docs/history.md
> >
> >
> > The commit to be voted upon:
> >
> https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=512bbee4aa24ef9fb8106d0286d1243679dce2d0
> >
> >
> > Its hash is 512bbee4aa24ef9fb8106d0286d1243679dce2d0
> >
> > Tag:
> >
> https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=tag;h=refs/tags/avatica-1.16.0-rc1
> >
> >
> > The artifacts to be voted on are located here:
> >
> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.16.0-rc1
> >
> > (revision 37181)
> >
> > The hashes of the artifacts are as follows:
> >
> 102d3ab0e90dd1db5e012a966d265bdfa8a0f24f9016a4187a6e5f0135a14770da124493dd2c7a18c9d8d8b9af5ecf4f5aceb90d48421251f38bc6ce6f5be697
>
> >
> > *apache-calcite-avatica-1.16.0-src.tar.gz
> >
> > A staged Maven repository is available for review at:
> >
> https://repository.apache.org/content/repositories/orgapachecalcite-1071/org/apache/calcite/
> >
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/francischuang.asc
> > https://www.apache.org/dist/calcite/KEYS
> >
> > N.B.
> > To create the jars and test Apache Calcite Avatica: "./gradlew build
> > -PskipSigning".
> >
> > If you do not have a Java environment available, you can run the tests
> > using docker. To do so, install docker and docker-compose, then run
> > "docker-compose run test" from the root of the directory.
> >
> > Please vote on releasing this package as Apache Calcite Avatica 1.16.0.
> >
> > The vote is open for the next 72 hours and passes if a majority of at
> > least three +1 PMC votes are cast.
> >
> > [ ] +1 Release this package as Apache Calcite 1.16.0
> > [ ]  0 I don't feel strongly about it, but I'm okay with the release
> > [ ] -1 Do not release this package because...
> >
> >
> > Here is my vote:
> >
> > +1 (binding)
> >
> > Francis
>

Re: [VOTE] Release apache-calcite-avatica-1.16.0 (release candidate 1)

[Francis Chuang]

Hey everyone,

Just a quick reminder that the vote for Avatica 1.16.0 rc1 is still open.

Francis

On 12/12/2019 9:20 am, Francis Chuang wrote:

Hi all,

I have created a build for Apache Calcite Avatica 1.16.0, release
candidate 1.

Thanks to everyone who has contributed to this release.

You can read the release notes here:
https://github.com/apache/calcite-avatica/blob/512bbee4aa24ef9fb8106d0286d1243679dce2d0/site/_docs/history.md 



The commit to be voted upon:
https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=512bbee4aa24ef9fb8106d0286d1243679dce2d0 



Its hash is 512bbee4aa24ef9fb8106d0286d1243679dce2d0

Tag:
https://gitbox.apache.org/repos/asf?p=calcite-avatica.git;a=tag;h=refs/tags/avatica-1.16.0-rc1 



The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-1.16.0-rc1 


(revision 37181)

The hashes of the artifacts are as follows:
102d3ab0e90dd1db5e012a966d265bdfa8a0f24f9016a4187a6e5f0135a14770da124493dd2c7a18c9d8d8b9af5ecf4f5aceb90d48421251f38bc6ce6f5be697 


*apache-calcite-avatica-1.16.0-src.tar.gz

A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1071/org/apache/calcite/ 



Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/francischuang.asc
https://www.apache.org/dist/calcite/KEYS

N.B.
To create the jars and test Apache Calcite Avatica: "./gradlew build 
-PskipSigning".


If you do not have a Java environment available, you can run the tests
using docker. To do so, install docker and docker-compose, then run
"docker-compose run test" from the root of the directory.

Please vote on releasing this package as Apache Calcite Avatica 1.16.0.

The vote is open for the next 72 hours and passes if a majority of at
least three +1 PMC votes are cast.

[ ] +1 Release this package as Apache Calcite 1.16.0
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...


Here is my vote:

+1 (binding)

Francis

[DISCUSS] Remove Kotlin

[Julian Hyde]

Vladimir proposed that we convert some tests to Kotlin. The general reaction 
was against the idea[1]. After receiving this feedback, he went ahead anyway[2].

I propose that we remove all Kotlin from our source code, including tests. The 
benefits of being a hybrid Java+Kotlin project do not outweigh the negatives. 
We should go back to being solely Java. (I would make an exception for 
build.gradle.kts, because build scripts are generally in a different language.)

Vladimir clearly has a lot of enthusiasm to change the build system, coding 
style, the languages we use. I tend to be more conservative (don’t fix things 
that aren’t broken). Speaking personally, I find working with Vladimir 
extremely stressful. Of course, a lot of the things he is removing are things 
that I personally have created, so I naturally take this more personally than 
most people. Still, his actions over the last few weeks have left me angry, 
depressed, and burned out with the project. 

Julian

[1] 
https://lists.apache.org/thread.html/c95bc24a10952ccaaa8ac1f959bf65aec450b8bf2fa36ba99dd0df08%40%3Cdev.calcite.apache.org%3E
 


[2] 
https://github.com/apache/calcite/commit/b93ec5a9edb7459696385e6adad67b92b6d406d7
 

Problems to validate ddl commands

[Anthony Louis]

When I try to validate a sql statement that contains "CREATE TABLE" it
throws an error that is described in this gist
https://gist.github.com/anthonylouisbsb/5f7d57886836cfac1742366722afcf41. I
would like to know if is possible to validate a query using ddl statements?

Re: Contribute to calcite

[Michael Mior]

I've added you as a contributor on JIRA. Welcome to Calcite!
--
Michael Mior
mm...@apache.org

Le lun. 16 déc. 2019 à 07:04, hailongwang <18868816...@163.com> a écrit :
>
> Hi all:
>
>
>   I want to contribute to calcite, could you please give me contribution 
> permission. My jira id is hailong wang. Thank you.
>
>
> Best.
> hailong wang

[jira] [Created] (CALCITE-3605) Semantics of relation operator changed after decorrelated

[Wang Yanlin (Jira)]

Wang Yanlin created CALCITE-3605:


 Summary: Semantics of relation operator changed after decorrelated
 Key: CALCITE-3605
 URL: https://issues.apache.org/jira/browse/CALCITE-3605
 Project: Calcite
  Issue Type: Bug
Reporter: Wang Yanlin


For sql
{code:java}
final String sql = "select deptno from (select deptno, empno from emp) p\n"
+ "where empno in\n"
+ "(select count(*) from dept where p.deptno = dept.deptno)";
{code}
before decorrelated, the relnode tree is
{code:java}
LogicalProject(DEPTNO=[$0])
  LogicalProject(DEPTNO=[$0], EMPNO=[$1])
LogicalFilter(condition=[=($1, $2)])
  LogicalCorrelate(correlation=[$cor0], joinType=[inner], 
requiredColumns=[{0}])
LogicalProject(DEPTNO=[$7], EMPNO=[$0])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
  LogicalProject($f0=[0])
LogicalFilter(condition=[=($cor0.DEPTNO, $0)])
  LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
after decorrelatd, the relnode tree is
{code:java}
LogicalProject(DEPTNO=[$0])
  LogicalJoin(condition=[AND(=($0, $2), =($1, $3))], joinType=[inner])
LogicalProject(DEPTNO=[$7], EMPNO=[$0])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalAggregate(group=[{0}], EXPR$0=[COUNT()])
  LogicalProject(DEPTNO=[$0], $f0=[0])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
however, these two relnode trees have different semantics.

Assume, the data in dept and emp is as below
{code:java}
EMP (deptno, empno)
3, 6
10, 1
8, 0

DEPT (deptno, name)
3, "a"
10, "b"
{code}
The output of the sql should be 
 +--+
|10|
|8|

+--+

but the output of the relnode after decorrelated is
 +--+
|10|

+--+



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CALCITE-3604) Test failed caused by localized exception message

[Feng Zhu (Jira)]

Feng Zhu created CALCITE-3604:
-

 Summary: Test failed caused by localized exception message
 Key: CALCITE-3604
 URL: https://issues.apache.org/jira/browse/CALCITE-3604
 Project: Calcite
  Issue Type: Bug
  Components: core
 Environment: OS: Windows7

JDK: 1.8.0_121

Locale: zh_CN
Reporter: Feng Zhu


When I fetch the recent master branch and build it, the tests added in 
CALCITE-3552 fail.

For example: *_SqlXmlFunctionsTest_*_#_*_testExtractValue_*
{code:java}
org.apache.calcite.test.SqlXmlFunctionsTest > testExtractValue() FAILED
java.lang.AssertionError: extractValue(cccddd, #)
Expected: is org.apache.calcite.runtime.CalciteException: Illegal behavior 
'javax.xml.xpath.XPathExpressionException: 
javax.xml.transform.TransformerException: A location path was expected, but the 
following token was encountered:  #' EXTRACTVALUE: document: 
'cccddd', xpath expression: '#'
 but: was cccddd', xpath expression: '#'>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
at 
org.apache.calcite.test.SqlXmlFunctionsTest.assertFailed(SqlXmlFunctionsTest.java:70)
at 
org.apache.calcite.test.SqlXmlFunctionsTest.assertExtractValueFailed(SqlXmlFunctionsTest.java:61)
at 
org.apache.calcite.test.SqlXmlFunctionsTest.testExtractValue(SqlXmlFunctionsTest.java:47)
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Contribute to calcite

[hailongwang]

Hi all:


  I want to contribute to calcite, could you please give me contribution 
permission. My jira id is hailong wang. Thank you.


Best.
hailong wang

[jira] [Created] (CALCITE-3603) SqlLateralOperator's unparse add additional keyword 'LATERAL' when the inner operator is SqlSnapshot

[Kevin Zhang (Jira)]

Kevin Zhang created CALCITE-3603:


 Summary: SqlLateralOperator's unparse add additional keyword 
'LATERAL' when the inner operator is SqlSnapshot
 Key: CALCITE-3603
 URL: https://issues.apache.org/jira/browse/CALCITE-3603
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.21.0
Reporter: Kevin Zhang


When joining with a dimension table using the following sql

{code:sql}
SELECT
  o.amout, o.currency, r.rate, o.amount * r.rate
FROM
  Orders AS o
  JOIN LatestRates FOR SYSTEM_TIME AS OF o.proctime AS r
  ON r.currency = o.currency
{code}

the unparsed sql is:

{code:sql}
SELECT `o`.`amout`, `o`.`currency`, `r`.`rate`, `o`.`amount` * `r`.`rate`
FROM `Orders` AS `o`
INNER JOIN LATERAL `LatestRates` FOR SYSTEM_TIME AS OF `o`.`proctime` AS `r` ON 
`r`.`currency` = `o`.`currency`
{code}
which has a syntax error because an additional "LATERAL" is added after "JOIN".

The problem lies in SqlLateralOperator's unparse method, if the kind of the 
first operand is SqlSnapshot, we should not write out the operator's name.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)