Re: [DISCUSS] restrict JDK test matrix

[Stamatis Zampetakis]

Hello,

It is not recommended to use EOL software so dropping those JDK versions
from the test matrix makes sense. Anyways it wouldn't be surprising if
Jenkins, Travis, Github Actions, etc., remove those EOL versions as well at
some point.

Best,
Stamatis

On Mon, Oct 3, 2022 at 3:15 PM Julian Hyde  wrote:

> It makes sense to only test on 8, 11, 17 and the latest. Testing on other
> versions is going to waste time checking on false negatives. I don’t
> remember whether there’s ever been an issue on, say, 15, that wasn’t also
> present in 11 or 17.
>
> Maybe it’s a distinction without a difference, but I think we should still
> support the full range of JDK versions.  If I submit a change that breaks
> the build on JDK 13, you should tell me and I should fix it. I don’t use
> sdkman and can create a JDK 13 environment easily enough from the JDK’s
> binary tarball.
>
> Julian
>
> > On Oct 3, 2022, at 5:38 AM, Alessandro Solimando <
> alessandro.solima...@gmail.com> wrote:
> >
> > Hello everyone,
> > I was checking a build failure
> > 
> related to
> > JDK15 and I wanted to try it locally, however I can't do it via sdkman
> >  (a "multi-platform software manager") as JDK is not
> > anymore available. This is not the first time, and it makes review tasks
> > complicated sometimes (in this specific case it seems an ENV issue, but
> > that's not the point here).
> >
> > I wanted to discuss with you if we really want to keep those "recent but
> > EOL" versions or not in our test matrix.
> >
> > I know that JDK8 is EOL too, but lots of projects are still based on it
> and
> > it's sadly running in PROD in many places for the same reason. In my
> (maybe
> > limited) experience, those who upgraded to newer versions (> 11), aren't
> > likely to get stuck at, say, 15 and can't move to 17. Is my assumption
> > correct in your experience?
> >
> > In my sdkman on MacOS I only see JDK 8, 11, 17, 20, 21, 22, and I
> strongly
> > suspect they are following some criteria based on LTS/EOL versions.
> >
> > Shall we try to do something similar for Calcite and remove non-LTS+EOL
> > versions higher than 11?
> >
> > Best regards,
> > Alessandro
>

[jira] [Created] (CALCITE-5306) Support LTS JDKs and latest in testing

[Alessandro Solimando (Jira)]

Alessandro Solimando created CALCITE-5306:
-

 Summary: Support LTS JDKs and latest in testing
 Key: CALCITE-5306
 URL: https://issues.apache.org/jira/browse/CALCITE-5306
 Project: Calcite
  Issue Type: Test
  Components: tests
Affects Versions: 1.32.0
Reporter: Alessandro Solimando
Assignee: Alessandro Solimando


Following [this 
discussion|https://lists.apache.org/thread/txh3n7r1sygqs69084z9m7g6r1hjbmn8] in 
the ML, we agreed on supporting only LTS JDK versions plus latest in our test 
environment (Github actions, AppVeyor and Travis). 

JDK 8 for the usual reasons is an exception to the rule and will be kept.

All non-LTS EOL versions will be upgraded to the next LTS version (_e.g._, JDK 
15 will be replaced by JDK 17).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] restrict JDK test matrix

[Alessandro Solimando]

Julian, Stamatis,
thanks for your input!

Since it seems that there is consensus around the topic, I have logged
CALCITE-5306 .

As soon as I have a PR ready, I will reply to this thread too, in order to
collect opinions and feedback.

Best regards,
Alessandro

On Tue, 4 Oct 2022 at 11:12, Stamatis Zampetakis  wrote:

> Hello,
>
> It is not recommended to use EOL software so dropping those JDK versions
> from the test matrix makes sense. Anyways it wouldn't be surprising if
> Jenkins, Travis, Github Actions, etc., remove those EOL versions as well at
> some point.
>
> Best,
> Stamatis
>
> On Mon, Oct 3, 2022 at 3:15 PM Julian Hyde  wrote:
>
> > It makes sense to only test on 8, 11, 17 and the latest. Testing on other
> > versions is going to waste time checking on false negatives. I don’t
> > remember whether there’s ever been an issue on, say, 15, that wasn’t also
> > present in 11 or 17.
> >
> > Maybe it’s a distinction without a difference, but I think we should
> still
> > support the full range of JDK versions.  If I submit a change that breaks
> > the build on JDK 13, you should tell me and I should fix it. I don’t use
> > sdkman and can create a JDK 13 environment easily enough from the JDK’s
> > binary tarball.
> >
> > Julian
> >
> > > On Oct 3, 2022, at 5:38 AM, Alessandro Solimando <
> > alessandro.solima...@gmail.com> wrote:
> > >
> > > Hello everyone,
> > > I was checking a build failure
> > > 
> > related to
> > > JDK15 and I wanted to try it locally, however I can't do it via sdkman
> > >  (a "multi-platform software manager") as JDK is
> not
> > > anymore available. This is not the first time, and it makes review
> tasks
> > > complicated sometimes (in this specific case it seems an ENV issue, but
> > > that's not the point here).
> > >
> > > I wanted to discuss with you if we really want to keep those "recent
> but
> > > EOL" versions or not in our test matrix.
> > >
> > > I know that JDK8 is EOL too, but lots of projects are still based on it
> > and
> > > it's sadly running in PROD in many places for the same reason. In my
> > (maybe
> > > limited) experience, those who upgraded to newer versions (> 11),
> aren't
> > > likely to get stuck at, say, 15 and can't move to 17. Is my assumption
> > > correct in your experience?
> > >
> > > In my sdkman on MacOS I only see JDK 8, 11, 17, 20, 21, 22, and I
> > strongly
> > > suspect they are following some criteria based on LTS/EOL versions.
> > >
> > > Shall we try to do something similar for Calcite and remove non-LTS+EOL
> > > versions higher than 11?
> > >
> > > Best regards,
> > > Alessandro
> >
>

Infix cast precedence

[Itiel Sadeh]

Hello,

I've encountered weird parsing of infix cast with the babel parser, where
given the
following query:
SELECT -1 :: INT FROM t;
It will parse it as
UNARY_MINUS( CAST( 1 AS INT )),
while i've expected it to be
CAST(-1 AS INT)

As i've looked at the code I saw that the precedence of the INFIX_CAST is
94, and the precedence of the UNARY_MINUS is 80.

Is there a reason for the INFIX_CAST's precedence to be that high? Other
binary operators such as BINARY_PLUS have precedence of 40.

Thanks,

Itiel

[jira] [Created] (CALCITE-5307) Quoting of functions interferes with MySQL execution

[Dirk (Jira)]

Dirk created CALCITE-5307:
-

 Summary: Quoting of functions interferes with MySQL execution
 Key: CALCITE-5307
 URL: https://issues.apache.org/jira/browse/CALCITE-5307
 Project: Calcite
  Issue Type: Bug
  Components: babel
 Environment: calcite 1.32.0
MySQL 5.7.14
Reporter: Dirk


When parsing a SQL statement with a function call and then translating this 
back to SQL, calcite puts the functions name in quotes. 

For example with this code snippet
{quote}    String sql = "SELECT ADDDATE('2008-01-02', 31)";
    SqlParser sqlParser = SqlParser.create(sql, SqlParser.config());
    SqlSelect sqlSelect = (SqlSelect) sqlParser.parseQuery();
    System.out.println("MysqlSqlDialect SQL with default config: " + 
sqlSelect.toSqlString(MysqlSqlDialect.DEFAULT));
    System.out.println("PostgresqlSqlDialect SQL with default config: " + 
sqlSelect.toSqlString(PostgresqlSqlDialect.DEFAULT));
{quote}
The output is 
{quote}MysqlSqlDialect SQL with default config: SELECT `ADDDATE`('2008-01-02', 
31)
PostgresqlSqlDialect SQL with default config: SELECT "ADDDATE"('2008-01-02', 31)
{quote}
Showing the ADDDATE function quoted in the dialect that is specified. In MySQL 
this is backticks.

However executing this  on MySQL gives us:


{quote}mysql> SELECT ADDDATE('2008-01-02', 31);
+---+
| ADDDATE('2008-01-02', 31) |
+---+
| 2008-02-02                |
+---+
1 row in set (0.00 sec)

mysql> SELECT `ADDDATE`('2008-01-02', 31);
ERROR 1046 (3D000): No database selected
{quote}
This is because in MySQL ADDDATE is an intrinsic function (it is part of the 
MySQL grammar ( e..g  
https://github.com/twitter-forks/mysql/blob/master/sql/sql_yacc.yy ) which does 
not allow for quoting.

There are probably 2 dozen MySQL functions that cannot be used because of this. 
In some cases there are workarounds, but in other cases there are not. This 
also applies to hints like "SELECT /*+ MAX_EXECUTION_TIME(200) */" which get 
quoted and then ignored by MySQL.

Would it be possible to change the quoting behavior to not add any quotes for 
functions and hints if the parser input SQL does not contain it?






 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CALCITE-5308) Add support to Avatica for microsecond-precision timestamps

[Will Noble (Jira)]

Will Noble created CALCITE-5308:
---

 Summary: Add support to Avatica for microsecond-precision 
timestamps
 Key: CALCITE-5308
 URL: https://issues.apache.org/jira/browse/CALCITE-5308
 Project: Calcite
  Issue Type: Bug
Reporter: Will Noble


Avatica [serializes 
timestamps|https://github.com/apache/calcite-avatica/blob/9dfc5cad3efe72e9b14513b15a988ba86ab5a4ea/core/src/main/java/org/apache/calcite/avatica/remote/TypedValue.java#L447]
 as the integer number of milliseconds since epoch. We would like support for 
microsecond precision.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Infix cast precedence

[Julian Hyde]

Infix cast comes from Postgres. Can someone find a table of operator precedence 
in Postgres? Perhaps write a test case involving operators with slightly higher 
and lower precedence, so we can check that Calcite is consistent.

> On Oct 4, 2022, at 10:20 AM, Itiel Sadeh  
> wrote:
> 
> Hello,
> 
> I've encountered weird parsing of infix cast with the babel parser, where
> given the
> following query:
> SELECT -1 :: INT FROM t;
> It will parse it as
> UNARY_MINUS( CAST( 1 AS INT )),
> while i've expected it to be
> CAST(-1 AS INT)
> 
> As i've looked at the code I saw that the precedence of the INFIX_CAST is
> 94, and the precedence of the UNARY_MINUS is 80.
> 
> Is there a reason for the INFIX_CAST's precedence to be that high? Other
> binary operators such as BINARY_PLUS have precedence of 40.
> 
> Thanks,
> 
> Itiel