date:20210602

[jira] [Created] (CALCITE-4633) Enable RelFieldTrimmer to trim fields on a distinct UNION

2021-06-02 Thread Sean Broeder (Jira)

Sean Broeder created CALCITE-4633:
-

 Summary: Enable RelFieldTrimmer to trim fields on a distinct UNION
 Key: CALCITE-4633
 URL: https://issues.apache.org/jira/browse/CALCITE-4633
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.26.0
Reporter: Sean Broeder
Assignee: Sean Broeder
 Fix For: 1.28.0


Should be able to push a project to trim fields on top of distinct union 
without changing results.



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

[jira] [Created] (CALCITE-4632) Exception in RelToSqlConverter: "Cannot convert x to DECIMAL(n, m) due to overflow"

2021-06-02 Thread Steven Talbot (Jira)

Steven Talbot created CALCITE-4632:
--

 Summary: Exception in RelToSqlConverter: "Cannot convert x to 
DECIMAL(n, m) due to overflow"
 Key: CALCITE-4632
 URL: https://issues.apache.org/jira/browse/CALCITE-4632
 Project: Calcite
  Issue Type: Bug
Reporter: Steven Talbot


Test in RelToSqlConverter.java
{code:java}
@Test void testSelectWhereInDecimal() {
  final Function relFn = b -> b
  .scan("EMP")
  .filter(
  b.or(b.isNull(b.field("COMM")),
  (b.in(b.field("COMM"), b.literal(new BigDecimal("1.0")), 
b.literal(new BigDecimal("2.0"))
  .build();
  final String expected = "SELECT *\n"
  + "FROM \"scott\".\"EMP\"\n"
  + "WHERE \"COMM\" IS NULL OR \"COMM\" IN (1.0, 2.0)";
  relFn(relFn).ok(expected);
}{code}
Stack trace:

 
{noformat}
Cannot convert 2.0 to DECIMAL(2, 1) due to overflow
java.lang.IllegalArgumentException: Cannot convert 2.0 to DECIMAL(2, 1) due 
to overflow
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:990)
at 
org.apache.calcite.rex.RexBuilder.makeExactLiteral(RexBuilder.java:1046)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1592)
at 
org.apache.calcite.rel.rel2sql.SqlImplementor$Context.lambda$toIn$2(SqlImplementor.java:937)
at 
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at 
com.google.common.collect.CollectSpliterators$1WithCharacteristics.lambda$forEachRemaining$1(CollectSpliterators.java:67)
at 
java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:110)
at 
com.google.common.collect.CollectSpliterators$1WithCharacteristics.forEachRemaining(CollectSpliterators.java:67)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at 
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at 
org.apache.calcite.rel.rel2sql.SqlImplementor$Context.toIn(SqlImplementor.java:939)
at 
org.apache.calcite.rel.rel2sql.SqlImplementor$Context.toSql(SqlImplementor.java:912)
at 
org.apache.calcite.rel.rel2sql.SqlImplementor$Context.toSql(SqlImplementor.java:804)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:338)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:531)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:134)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitInput(RelToSqlConverter.java:142)
at 
org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:185)
at 
org.apache.calcite.rel.rel2sql.SqlImplementor.visitInput(SqlImplementor.java:173)
at 
org.apache.calcite.rel.rel2sql.SqlImplementor.visitRoot(SqlImplementor.java:153)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.toSql(RelToSqlConverterTest.java:216)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.toSql(RelToSqlConverterTest.java:204)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.access$300(RelToSqlConverterTest.java:111)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.exec(RelToSqlConverterTest.java:5999)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:5967)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testSelectWhereInDecimal(RelToSqlConverterTest.java:339){noformat}
 

Almost certainly because we just grab the type of the first arg at 
https://github.com/apache/calcite/blob/204b5ab42d9e365c55636cd0aca9f750f4d50e5d/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L801-L804,
 which in a decimal type is not guaranteed to be compatible with the remainder 
of the args. Probably need to call one of the type normalizing functions? 

 



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

Re: RelFieldTrimmer on union distinct

2021-06-02 Thread Julian Hyde

I ran those queries against Calcite. Calcite gives the correct result. 
RelFieldTrimmer does the right thing.

I was explaining, in simple terms, what would break if you made your proposed 
change to RelFieldTrimmer.

> On Jun 2, 2021, at 3:12 PM, Sean Broeder  wrote:
> 
> Thank you Julian.  
> 
> I am able to reproduce your findings.  
> 
> I am curious if the results highlight a bug in Calcite where we should expect 
> 4 to be returned or is this a query that Calcite should not support?
> 
> Sean
> 
>> On Jun 2, 2021, at 11:37 AM, Julian Hyde  wrote:
>> 
>> Here’s a query that would give the wrong answer if you trim:
>> 
>> select count(*) from (
>>   select deptno from scott.emp
>>   union
>>   select deptno from scott.dept);
>> 
>> returns 4. Note that ‘deptno’ is not used. But when I trim it away,
>> 
>> select count(*) from (
>>   select 'a' from scott.emp
>>   union
>>   select 'a' from scott.dept);
>> 
>> returns 1. (I included ‘a’ because SQL doesn’t allow an empty SELECT clause. 
>> It doesn’t affect the reasoning.)
>> 
>> Julian
>> 
>> 
>> 
>>> On Jun 2, 2021, at 6:03 AM, Sean Broeder  wrote:
>>> 
>>> Currently the RefFieldTrimmer only trims on a UNION ALL operation.  I've
>>> been experimenting to see if it is also possible to trim on UNION
>>> DISTINCT.  Is there a simple query that demonstrates why this is not
>>> possible?
>>> 
>>> Thanks,
>>> Sean
>> 
>

Re: Minified javascript in source releases

2021-06-02 Thread Francis Chuang

+1 for removing those 2 scripts. They are for compatibility with very
old browsers that have been discontinued for many years, so it makes
sense to reduce the bloat.

Francis

On 3/06/2021 5:25 am, Julian Hyde wrote:

+0 to remove them entirely, if that is possible.

-1 to keep in git but remove from source releases. We are already in
compliance with Apache policy, best I can tell.

On Wed, Jun 2, 2021 at 12:08 PM Haisheng Yuan wrote:

+1 for removing them entirely.

Thanks,
Haisheng Yuan

On 2021/06/02 13:36:05, Alessandro Solimando
wrote:

Hi all,
+1 for removing them as well, all the mentioned sw versions in [5,6]
are extremely, extremely old.

Best regards,
Alessandro

On Wed, 2 Jun 2021 at 14:38, Michael Mior wrote:

+1 for removing these entirely. I don't believe they are currently necessary.
--
Michael Mior
mm...@apache.org

Le mer. 2 juin 2021 à 06:13, Stamatis Zampetakis a écrit :

Hi all,

In the recent votes for Calcite [1] and Avatica [2] there were some -1
votes regarding minified javascript files present in the source releases.

The concerns are raised for the following files:
site/js/html5shiv.min.js
site/js/respond.min.js

From discussions in other lists it seems that there are Apache source
releases including minified files so I don't think we are violating any
policy by including them but there are deferring opinions on this topic
[3,4].

To avoid bringing back the discussion to if minified javascript should be
present or not I would like to propose one of the following alternatives:

1. It seems that both of the aforementioned scripts [5,6] are used for
compatibility reasons with old browsers. I think most of the people are not
using these browsers anymore so I would suggest removing them altogether
from the code.

2. If for some reason we need to keep them then we could directly use the
non minified version. The difference of minified vs unminified for both
files is ~6KB so I doubt it will have any real impact with the internet
connections that we use nowadays.

What do you think?

Best,
Stamatis

[1]
https://lists.apache.org/thread.html/r049cf5b953eb5824ba37df21094dd7c1e92146d659db4735ad121593%40%3Cdev.calcite.apache.org%3E
[2]
https://lists.apache.org/thread.html/r074720fc062bde09a7e69dc77f77754c7fd4c22f1357514f6b2196d0%40%3Cdev.calcite.apache.org%3E
[3]
https://lists.apache.org/thread.html/rcddc30dd1f0c7f20709e09de7202d4d6885d6235a7fce1c1ab46e4ed%40%3Clegal-discuss.apache.org%3E
[4]
http://mail-archives.apache.org/mod_mbox/incubator-general/201805.mbox/%3c89a47c0b-e74e-4571-b282-dbe505291...@classsoftware.com%3e
[5] https://github.com/scottjehl/Respond
[6] https://github.com/aFarkas/html5shiv

Re: RelFieldTrimmer on union distinct

2021-06-02 Thread Sean Broeder

Thank you Julian.  

I am able to reproduce your findings.  

I am curious if the results highlight a bug in Calcite where we should expect 4 
to be returned or is this a query that Calcite should not support?

Sean

> On Jun 2, 2021, at 11:37 AM, Julian Hyde  wrote:
> 
> Here’s a query that would give the wrong answer if you trim:
> 
>  select count(*) from (
>select deptno from scott.emp
>union
>select deptno from scott.dept);
> 
> returns 4. Note that ‘deptno’ is not used. But when I trim it away,
> 
>  select count(*) from (
>select 'a' from scott.emp
>union
>select 'a' from scott.dept);
> 
> returns 1. (I included ‘a’ because SQL doesn’t allow an empty SELECT clause. 
> It doesn’t affect the reasoning.)
> 
> Julian
> 
> 
> 
>> On Jun 2, 2021, at 6:03 AM, Sean Broeder  wrote:
>> 
>> Currently the RefFieldTrimmer only trims on a UNION ALL operation.  I've
>> been experimenting to see if it is also possible to trim on UNION
>> DISTINCT.  Is there a simple query that demonstrates why this is not
>> possible?
>> 
>> Thanks,
>> Sean
>

Re: Deduplicate correlate variables question.

2021-06-02 Thread James Starr

If it is de facto deprecated, then could it not just be deprecated with a
comment stating why it has not been deleted?  Calcite seems to have several
API that are defacto deprecated and there is no way of knowing by reading
the code.  This would personally have made me much simpler for myself to
get ramped on the calcite code base.

James

On Wed, Jun 2, 2021 at 12:07 PM Julian Hyde  wrote:

> Master is a moving target. Apparently you are using a version of the
> code from sometime in March. These links work better:
>
> [1]
> https://github.com/apache/calcite/blob/796675c9b33e0461bc45a72780162d474a4b098b/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L2881
>
> [2]
> https://github.com/apache/calcite/blob/796675c9b33e0461bc45a72780162d474a4b098b/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L6209
>
> I don't know the exact cause of what you are seeing, but when you set
> "expand=false" you are choosing a newer (and better) code path. We do
> not have feature parity between the code paths. Nor do we write tests
> for both code paths.
>
> Some day I'd like to officially deprecate, then obsolete,
> "expand=true". It is de facto deprecated because we put more effort
> into the "expand=false" path.
>
> Julian
>
>
> On Fri, May 28, 2021 at 1:19 AM stanilovsky evgeny
>  wrote:
> >
> > Hi, calciters )
> >
> > I am trying to figure out why DeduplicateCorrelateVariables [1] is called
> > only if withExpand [2] flag is true ? Why we don`t need to deduplicate in
> > appropriate case ?
> >
> > [1]
> >
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L2881
> >
> > [2]
> >
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L6209
> >
> > Thanks !
>

Re: Minified javascript in source releases

2021-06-02 Thread Julian Hyde

+0 to remove them entirely, if that is possible.

-1 to keep in git but remove from source releases. We are already in
compliance with Apache policy, best I can tell.


On Wed, Jun 2, 2021 at 12:08 PM Haisheng Yuan  wrote:
>
> +1 for removing them entirely.
>
> Thanks,
> Haisheng Yuan
>
> On 2021/06/02 13:36:05, Alessandro Solimando  
> wrote:
> > Hi all,
> > +1 for removing them as well, all the mentioned sw versions in [5,6]
> > are extremely, extremely old.
> >
> > Best regards,
> > Alessandro
> >
> > On Wed, 2 Jun 2021 at 14:38, Michael Mior  wrote:
> > >
> > > +1 for removing these entirely. I don't believe they are currently 
> > > necessary.
> > > --
> > > Michael Mior
> > > mm...@apache.org
> > >
> > > Le mer. 2 juin 2021 à 06:13, Stamatis Zampetakis  a 
> > > écrit :
> > > >
> > > > Hi all,
> > > >
> > > > In the recent votes for Calcite [1] and Avatica [2] there were some -1
> > > > votes regarding minified javascript files present in the source 
> > > > releases.
> > > >
> > > > The concerns are raised for the following files:
> > > > site/js/html5shiv.min.js
> > > > site/js/respond.min.js
> > > >
> > > > From discussions in other lists it seems that there are Apache source
> > > > releases including minified files so I don't think we are violating any
> > > > policy by including them but there are deferring opinions on this topic
> > > > [3,4].
> > > >
> > > > To avoid bringing back the discussion to if minified javascript should 
> > > > be
> > > > present or not I would like to propose one of the following 
> > > > alternatives:
> > > >
> > > > 1. It seems that both of the aforementioned scripts [5,6] are used for
> > > > compatibility reasons with old browsers. I think most of the people are 
> > > > not
> > > > using these browsers anymore so I would suggest removing them altogether
> > > > from the code.
> > > >
> > > > 2. If for some reason we need to keep them then we could directly use 
> > > > the
> > > > non minified version. The difference of minified vs unminified for both
> > > > files is ~6KB so I doubt it will have any real impact with the internet
> > > > connections that we use nowadays.
> > > >
> > > > What do you think?
> > > >
> > > > Best,
> > > > Stamatis
> > > >
> > > > [1]
> > > > https://lists.apache.org/thread.html/r049cf5b953eb5824ba37df21094dd7c1e92146d659db4735ad121593%40%3Cdev.calcite.apache.org%3E
> > > > [2]
> > > > https://lists.apache.org/thread.html/r074720fc062bde09a7e69dc77f77754c7fd4c22f1357514f6b2196d0%40%3Cdev.calcite.apache.org%3E
> > > > [3]
> > > > https://lists.apache.org/thread.html/rcddc30dd1f0c7f20709e09de7202d4d6885d6235a7fce1c1ab46e4ed%40%3Clegal-discuss.apache.org%3E
> > > > [4]
> > > > http://mail-archives.apache.org/mod_mbox/incubator-general/201805.mbox/%3c89a47c0b-e74e-4571-b282-dbe505291...@classsoftware.com%3e
> > > > [5] https://github.com/scottjehl/Respond
> > > > [6] https://github.com/aFarkas/html5shiv
> >

Re: Minified javascript in source releases

2021-06-02 Thread Haisheng Yuan

+1 for removing them entirely.

Thanks,
Haisheng Yuan

On 2021/06/02 13:36:05, Alessandro Solimando  
wrote: 
> Hi all,
> +1 for removing them as well, all the mentioned sw versions in [5,6]
> are extremely, extremely old.
> 
> Best regards,
> Alessandro
> 
> On Wed, 2 Jun 2021 at 14:38, Michael Mior  wrote:
> >
> > +1 for removing these entirely. I don't believe they are currently 
> > necessary.
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le mer. 2 juin 2021 à 06:13, Stamatis Zampetakis  a 
> > écrit :
> > >
> > > Hi all,
> > >
> > > In the recent votes for Calcite [1] and Avatica [2] there were some -1
> > > votes regarding minified javascript files present in the source releases.
> > >
> > > The concerns are raised for the following files:
> > > site/js/html5shiv.min.js
> > > site/js/respond.min.js
> > >
> > > From discussions in other lists it seems that there are Apache source
> > > releases including minified files so I don't think we are violating any
> > > policy by including them but there are deferring opinions on this topic
> > > [3,4].
> > >
> > > To avoid bringing back the discussion to if minified javascript should be
> > > present or not I would like to propose one of the following alternatives:
> > >
> > > 1. It seems that both of the aforementioned scripts [5,6] are used for
> > > compatibility reasons with old browsers. I think most of the people are 
> > > not
> > > using these browsers anymore so I would suggest removing them altogether
> > > from the code.
> > >
> > > 2. If for some reason we need to keep them then we could directly use the
> > > non minified version. The difference of minified vs unminified for both
> > > files is ~6KB so I doubt it will have any real impact with the internet
> > > connections that we use nowadays.
> > >
> > > What do you think?
> > >
> > > Best,
> > > Stamatis
> > >
> > > [1]
> > > https://lists.apache.org/thread.html/r049cf5b953eb5824ba37df21094dd7c1e92146d659db4735ad121593%40%3Cdev.calcite.apache.org%3E
> > > [2]
> > > https://lists.apache.org/thread.html/r074720fc062bde09a7e69dc77f77754c7fd4c22f1357514f6b2196d0%40%3Cdev.calcite.apache.org%3E
> > > [3]
> > > https://lists.apache.org/thread.html/rcddc30dd1f0c7f20709e09de7202d4d6885d6235a7fce1c1ab46e4ed%40%3Clegal-discuss.apache.org%3E
> > > [4]
> > > http://mail-archives.apache.org/mod_mbox/incubator-general/201805.mbox/%3c89a47c0b-e74e-4571-b282-dbe505291...@classsoftware.com%3e
> > > [5] https://github.com/scottjehl/Respond
> > > [6] https://github.com/aFarkas/html5shiv
>

Re: Deduplicate correlate variables question.

2021-06-02 Thread Julian Hyde

Master is a moving target. Apparently you are using a version of the
code from sometime in March. These links work better:

[1] 
https://github.com/apache/calcite/blob/796675c9b33e0461bc45a72780162d474a4b098b/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L2881

[2] 
https://github.com/apache/calcite/blob/796675c9b33e0461bc45a72780162d474a4b098b/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L6209

I don't know the exact cause of what you are seeing, but when you set
"expand=false" you are choosing a newer (and better) code path. We do
not have feature parity between the code paths. Nor do we write tests
for both code paths.

Some day I'd like to officially deprecate, then obsolete,
"expand=true". It is de facto deprecated because we put more effort
into the "expand=false" path.

Julian

On Fri, May 28, 2021 at 1:19 AM stanilovsky evgeny
 wrote:
>
> Hi, calciters )
>
> I am trying to figure out why DeduplicateCorrelateVariables [1] is called
> only if withExpand [2] flag is true ? Why we don`t need to deduplicate in
> appropriate case ?
>
> [1]
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L2881
>
> [2]
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L6209
>
> Thanks !

Re: [VOTE] Release apache-calcite-1.27.0 (release candidate 0)

2021-06-02 Thread Igor Lozynskyi

Thanks Stamatis for taking care of this release.

+1


- Calcite tests locally (macOS Catalina 10.15.7 + JVM 11.0.8 (AdoptOpenJDK 
11.0.8+10) + Gradle 6.8.3): ok
- Unit and integration tests of the downstream project using Calcite 1.27.0 RC0 
: ok

Igor
On 31 May 2021, 18:29 +0300, dev@calcite.apache.org, wrote:
>
> Thanks Stamatis for taking care of this release.
>
> +1 (binding)
> - Signature: ok
> - Checksum: ok
> - Tests locally (Windows10 + JDK 1.8.0_212 + Gradle 6.8.3): ok
> - Calcite-based application test suite: ok
> - Release notes: ok (apart from the minor date issue mentioned by
> Alessandro)
>
> Ruben

Re: RelFieldTrimmer on union distinct

2021-06-02 Thread Julian Hyde

Here’s a query that would give the wrong answer if you trim:

  select count(*) from (
select deptno from scott.emp
union
select deptno from scott.dept);

returns 4. Note that ‘deptno’ is not used. But when I trim it away,

  select count(*) from (
select 'a' from scott.emp
union
select 'a' from scott.dept);

returns 1. (I included ‘a’ because SQL doesn’t allow an empty SELECT clause. It 
doesn’t affect the reasoning.)

Julian

> On Jun 2, 2021, at 6:03 AM, Sean Broeder  wrote:
> 
> Currently the RefFieldTrimmer only trims on a UNION ALL operation.  I've
> been experimenting to see if it is also possible to trim on UNION
> DISTINCT.  Is there a simple query that demonstrates why this is not
> possible?
> 
> Thanks,
> Sean

[jira] [Created] (CALCITE-4631) sql->rel->sql bug with unparsing timestampdiff

2021-06-02 Thread Steven Talbot (Jira)

Steven Talbot created CALCITE-4631:
--

 Summary: sql->rel->sql bug with unparsing timestampdiff
 Key: CALCITE-4631
 URL: https://issues.apache.org/jira/browse/CALCITE-4631
 Project: Calcite
  Issue Type: Bug
Reporter: Steven Talbot


class org.apache.calcite.sql.SqlSyntax$7: SPECIAL

 

e.g. the following test in RelToSqlConverter.java demonstrates the end-to-end 
problem:

 
{code:java}
@Test void testTimestampDiff() {
 final String query = "select timestampdiff(day, a.\"hire_date\", 
b.\"hire_date\") "
 + "from \"employee\" a join \"employee\" b using (\"employee_id\")";
 final String expected = "TBD, can't get it to generate right now";
 sql(query).ok(expected);
}{code}
throws, top of stack:
{noformat}
class org.apache.calcite.sql.SqlSyntax$7: SPECIAL
java.lang.UnsupportedOperationException: class 
org.apache.calcite.sql.SqlSyntax$7: SPECIAL
at org.apache.calcite.util.Util.needToImplement(Util.java:1101)
at org.apache.calcite.sql.SqlSyntax$7.unparse(SqlSyntax.java:129)
at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:383)
at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:455)
at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:123)
at org.apache.calcite.sql.SqlUtil.unparseBinarySyntax(SqlUtil.java:425)
at org.apache.calcite.sql.SqlSyntax$4.unparse(SqlSyntax.java:78)
at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:383)
at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:455)
at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
at 
org.apache.calcite.sql.fun.SqlCastFunction.unparse(SqlCastFunction.java:181)
at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:455)
at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
at 
org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1304)
at 
org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1284)
at 
org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1081)
at 
org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:455)
at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.toSql(RelToSqlConverterTest.java:216){noformat}
>From the debugger, it looks like a SqlKind.REINTERPRET operator gets generated 
>by the SqlToRelConverter, and nothing knows how to handle that unparsing to 
>SQL.

 



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

[jira] [Created] (CALCITE-4630) Wrong logical plan for INNER JOIN with subquery

2021-06-02 Thread Dmitry Sysolyatin (Jira)

Dmitry Sysolyatin created CALCITE-4630:
--

 Summary: Wrong logical plan for INNER JOIN with subquery
 Key: CALCITE-4630
 URL: https://issues.apache.org/jira/browse/CALCITE-4630
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.26.0
Reporter: Dmitry Sysolyatin


I tried to execute the following query:
{code:sql}
SELECT
d.name,
d.timestamp_ns
FROM trucks t
INNER JOIN LATERAL (
  SELECT
  name, timestamp_ns, fuel_state
   FROM
  trucks_diagnostics
   WHERE
   trucks_diagnostics.name = t.name
ORDER BY timestamp_ns DESC
LIMIT 1) d ON true WHERE s.fleet = 'South' AND d.fuel_state < 0.1
{code}
calcite generates me the following logical plan:
{code:java}
LogicalProject(name=[$8], timestamp_ns=[$9])
  LogicalCorrelate(correlation=[$cor0], joinType=[inner], requiredColumns=[{4}])
LogicalFilter(condition=[=(CAST($6):VARCHAR, 'South')])
  DataTableScan
LogicalFilter(condition=[<($2, 0.1:DECIMAL(2, 1))])
  LogicalSort(sort0=[$1], dir0=[DESC], fetch=[1])
LogicalProject(name=[$4], timestamp_ns=[$0], fuel_state=[$1])
  LogicalFilter(condition=[=(CAST($4):VARCHAR, 
CAST($cor0.name):VARCHAR)])
DataTableScan
{code}
But `LogicalFilter(condition=[<($2, 0.1:DECIMAL(2, 1))])` should not be inside 
LogicalCorrelate . It should be upper than LogicalCorrelate



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

Re: Minified javascript in source releases

2021-06-02 Thread Alessandro Solimando

Hi all,
+1 for removing them as well, all the mentioned sw versions in [5,6]
are extremely, extremely old.

Best regards,
Alessandro

On Wed, 2 Jun 2021 at 14:38, Michael Mior  wrote:
>
> +1 for removing these entirely. I don't believe they are currently necessary.
> --
> Michael Mior
> mm...@apache.org
>
> Le mer. 2 juin 2021 à 06:13, Stamatis Zampetakis  a écrit :
> >
> > Hi all,
> >
> > In the recent votes for Calcite [1] and Avatica [2] there were some -1
> > votes regarding minified javascript files present in the source releases.
> >
> > The concerns are raised for the following files:
> > site/js/html5shiv.min.js
> > site/js/respond.min.js
> >
> > From discussions in other lists it seems that there are Apache source
> > releases including minified files so I don't think we are violating any
> > policy by including them but there are deferring opinions on this topic
> > [3,4].
> >
> > To avoid bringing back the discussion to if minified javascript should be
> > present or not I would like to propose one of the following alternatives:
> >
> > 1. It seems that both of the aforementioned scripts [5,6] are used for
> > compatibility reasons with old browsers. I think most of the people are not
> > using these browsers anymore so I would suggest removing them altogether
> > from the code.
> >
> > 2. If for some reason we need to keep them then we could directly use the
> > non minified version. The difference of minified vs unminified for both
> > files is ~6KB so I doubt it will have any real impact with the internet
> > connections that we use nowadays.
> >
> > What do you think?
> >
> > Best,
> > Stamatis
> >
> > [1]
> > https://lists.apache.org/thread.html/r049cf5b953eb5824ba37df21094dd7c1e92146d659db4735ad121593%40%3Cdev.calcite.apache.org%3E
> > [2]
> > https://lists.apache.org/thread.html/r074720fc062bde09a7e69dc77f77754c7fd4c22f1357514f6b2196d0%40%3Cdev.calcite.apache.org%3E
> > [3]
> > https://lists.apache.org/thread.html/rcddc30dd1f0c7f20709e09de7202d4d6885d6235a7fce1c1ab46e4ed%40%3Clegal-discuss.apache.org%3E
> > [4]
> > http://mail-archives.apache.org/mod_mbox/incubator-general/201805.mbox/%3c89a47c0b-e74e-4571-b282-dbe505291...@classsoftware.com%3e
> > [5] https://github.com/scottjehl/Respond
> > [6] https://github.com/aFarkas/html5shiv

RelFieldTrimmer on union distinct

2021-06-02 Thread Sean Broeder

Currently the RefFieldTrimmer only trims on a UNION ALL operation.  I've
been experimenting to see if it is also possible to trim on UNION
DISTINCT.  Is there a simple query that demonstrates why this is not
possible?

Thanks,
Sean

Re: Minified javascript in source releases

2021-06-02 Thread Michael Mior

+1 for removing these entirely. I don't believe they are currently necessary.
--
Michael Mior
mm...@apache.org

Le mer. 2 juin 2021 à 06:13, Stamatis Zampetakis  a écrit :
>
> Hi all,
>
> In the recent votes for Calcite [1] and Avatica [2] there were some -1
> votes regarding minified javascript files present in the source releases.
>
> The concerns are raised for the following files:
> site/js/html5shiv.min.js
> site/js/respond.min.js
>
> From discussions in other lists it seems that there are Apache source
> releases including minified files so I don't think we are violating any
> policy by including them but there are deferring opinions on this topic
> [3,4].
>
> To avoid bringing back the discussion to if minified javascript should be
> present or not I would like to propose one of the following alternatives:
>
> 1. It seems that both of the aforementioned scripts [5,6] are used for
> compatibility reasons with old browsers. I think most of the people are not
> using these browsers anymore so I would suggest removing them altogether
> from the code.
>
> 2. If for some reason we need to keep them then we could directly use the
> non minified version. The difference of minified vs unminified for both
> files is ~6KB so I doubt it will have any real impact with the internet
> connections that we use nowadays.
>
> What do you think?
>
> Best,
> Stamatis
>
> [1]
> https://lists.apache.org/thread.html/r049cf5b953eb5824ba37df21094dd7c1e92146d659db4735ad121593%40%3Cdev.calcite.apache.org%3E
> [2]
> https://lists.apache.org/thread.html/r074720fc062bde09a7e69dc77f77754c7fd4c22f1357514f6b2196d0%40%3Cdev.calcite.apache.org%3E
> [3]
> https://lists.apache.org/thread.html/rcddc30dd1f0c7f20709e09de7202d4d6885d6235a7fce1c1ab46e4ed%40%3Clegal-discuss.apache.org%3E
> [4]
> http://mail-archives.apache.org/mod_mbox/incubator-general/201805.mbox/%3c89a47c0b-e74e-4571-b282-dbe505291...@classsoftware.com%3e
> [5] https://github.com/scottjehl/Respond
> [6] https://github.com/aFarkas/html5shiv

Minified javascript in source releases

2021-06-02 Thread Stamatis Zampetakis

Hi all,

In the recent votes for Calcite [1] and Avatica [2] there were some -1
votes regarding minified javascript files present in the source releases.

The concerns are raised for the following files:
site/js/html5shiv.min.js
site/js/respond.min.js

>From discussions in other lists it seems that there are Apache source
releases including minified files so I don't think we are violating any
policy by including them but there are deferring opinions on this topic
[3,4].

To avoid bringing back the discussion to if minified javascript should be
present or not I would like to propose one of the following alternatives:

1. It seems that both of the aforementioned scripts [5,6] are used for
compatibility reasons with old browsers. I think most of the people are not
using these browsers anymore so I would suggest removing them altogether
from the code.

2. If for some reason we need to keep them then we could directly use the
non minified version. The difference of minified vs unminified for both
files is ~6KB so I doubt it will have any real impact with the internet
connections that we use nowadays.

What do you think?

Best,
Stamatis

[1]
https://lists.apache.org/thread.html/r049cf5b953eb5824ba37df21094dd7c1e92146d659db4735ad121593%40%3Cdev.calcite.apache.org%3E
[2]
https://lists.apache.org/thread.html/r074720fc062bde09a7e69dc77f77754c7fd4c22f1357514f6b2196d0%40%3Cdev.calcite.apache.org%3E
[3]
https://lists.apache.org/thread.html/rcddc30dd1f0c7f20709e09de7202d4d6885d6235a7fce1c1ab46e4ed%40%3Clegal-discuss.apache.org%3E
[4]
http://mail-archives.apache.org/mod_mbox/incubator-general/201805.mbox/%3c89a47c0b-e74e-4571-b282-dbe505291...@classsoftware.com%3e
[5] https://github.com/scottjehl/Respond
[6] https://github.com/aFarkas/html5shiv

Re: [VOTE] Release apache-calcite-1.27.0 (release candidate 0)

2021-06-02 Thread Ruben Q L

Thanks Stamatis for taking care of this release.

+1 (binding)
- Signature: ok
- Checksum: ok
- Tests locally (Windows10 + JDK 1.8.0_212 + Gradle 6.8.3): ok
- Calcite-based application test suite: ok
- Release notes: ok (apart from the minor date issue mentioned by
Alessandro)

Ruben


On Wed, Jun 2, 2021 at 12:19 AM Haisheng Yuan  wrote:

> Thank you for pushing the new release forward, Stamatis.
>
> 1. Checked checksum and signature: OK
> 2. Ran Gradle test: OK
> 3. Checked release notes: OK
>
> Gradle 6.8.3, Java env: openjdk version "1.8.0_292", MacOS 10.15.7
> (19H1030).
>
> +1 (binding)
>
> Thanks,
> Haisheng Yuan
>
> On 2021/06/01 22:28:40, Julian Hyde  wrote:
> > FYI, I have just discovered
> https://issues.apache.org/jira/browse/CALCITE-4629 <
> https://issues.apache.org/jira/browse/CALCITE-4629> in 1.27 RC 0. I don’t
> have a repro case. I don’t think it is a show-stopper so my vote remains +1.
> >
> > > On Jun 1, 2021, at 2:59 PM, Julian Hyde 
> wrote:
> > >
> > > +1
> > >
> > > Downloaded, checked hashes and signature, compared tar.gz contents to
> git commit 60f07118f3. Confirmed that gradle-wrapper.jar is missing from
> tar.gz. Using instructions in site/_docs/howto.md, downloaded and installed
> gradle-6.8.3 from https://gradle.org/releases/ <
> https://gradle.org/releases/>, and compiled and ran tests using Ubuntu
> Linux, JDK 11.0.4, Gradle 6.8.1 and 6.8.3.
> > >
> > > Checked LICENSE, NOTICE. Ran RAT.
> > >
> > > Julian
> > >
> > >
> > >> On May 31, 2021, at 8:28 AM, Stamatis Zampetakis  > wrote:
> > >>
> > >> Hi all,
> > >>
> > >> I have created a build for Apache Calcite 1.27.0, release
> > >> candidate 0.
> > >>
> > >> Thanks to everyone who has contributed to this release.
> > >>
> > >> You can read the release notes here:
> > >>
> https://github.com/apache/calcite/blob/calcite-1.27.0-rc0/site/_docs/history.md
> <
> https://github.com/apache/calcite/blob/calcite-1.27.0-rc0/site/_docs/history.md
> >
> > >>
> > >> The commit to be voted upon:
> > >>
> https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=60f07118f31776462ea35ffdaa1f46c633251f69
> > >>
> > >> Its hash is 60f07118f31776462ea35ffdaa1f46c633251f69
> > >>
> > >> The artifacts to be voted on are located here:
> > >>
> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.27.0-rc0
> > >> (revision 48026)
> > >>
> > >> The hashes of the artifacts are as follows:
> > >>
> 6e81b8b155cbece67d5b0c3f81ee3cf086da7e28b95d20ad8d819080b6caaf03f021af00339e9d70a2d7b1a0b27a86fac14ad94c0a2967a12991fb9170dee4d3
> > >> *apache-calcite-1.27.0-src.tar.gz
> > >>
> > >> A staged Maven repository is available for review at:
> > >>
> https://repository.apache.org/content/repositories/orgapachecalcite-1115/org/apache/calcite/
> > >>
> > >> Release artifacts are signed with the following key:
> > >> https://people.apache.org/keys/committer/zabetak.asc
> > >> https://www.apache.org/dist/calcite/KEYS
> > >>
> > >> To create the jars and test Apache Calcite: "gradle build" (requires
> an
> > >> appropriate Gradle/JDK installation).
> > >>
> > >> Please vote on releasing this package as Apache Calcite 1.27.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.27.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)
> > >>
> > >> Stamatis
> > >
> >
> >
>

[jira] [Created] (CALCITE-4633) Enable RelFieldTrimmer to trim fields on a distinct UNION

[jira] [Created] (CALCITE-4632) Exception in RelToSqlConverter: "Cannot convert x to DECIMAL(n, m) due to overflow"

Re: RelFieldTrimmer on union distinct

Re: Minified javascript in source releases

Re: RelFieldTrimmer on union distinct

Re: Deduplicate correlate variables question.

Re: Minified javascript in source releases

Re: Minified javascript in source releases

Re: Deduplicate correlate variables question.

Re: [VOTE] Release apache-calcite-1.27.0 (release candidate 0)

Re: RelFieldTrimmer on union distinct

[jira] [Created] (CALCITE-4631) sql->rel->sql bug with unparsing timestampdiff

[jira] [Created] (CALCITE-4630) Wrong logical plan for INNER JOIN with subquery

Re: Minified javascript in source releases

RelFieldTrimmer on union distinct

Re: Minified javascript in source releases

Minified javascript in source releases

Re: [VOTE] Release apache-calcite-1.27.0 (release candidate 0)

18 matches

Site Navigation

Mail list logo

Footer information