[jira] [Created] (CALCITE-6377) Time expression causes IllegalStateException

[Mihai Budiu (Jira)]

Mihai Budiu created CALCITE-6377:


 Summary: Time expression causes IllegalStateException
 Key: CALCITE-6377
 URL: https://issues.apache.org/jira/browse/CALCITE-6377
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.36.0
Reporter: Mihai Budiu


The following SqlOperatorTest causes an exception:

{code:java}
final SqlOperatorFixture f = fixture();
f.checkScalar("time '12:03:01' + interval '25' day",
"12:03:01", "TIME(0) NOT NULL");
{code}

The exception is:

{code}
Caused by: java.lang.IllegalStateException: Unable to implement 
EnumerableCalc(expr#0=[{inputs}], expr#1=[12:03:01], 
expr#2=[216000:INTERVAL DAY], expr#3=[+($t1, $t2)], EXPR$0=[$t3]): rowcount 
= 1.0, cumulative cost = {2.0 rows, 6.0 cpu, 0.0 io}, id = 20
  EnumerableValues(tuples=[[{ 0 }]]): rowcount = 1.0, cumulative cost = {1.0 
rows, 1.0 cpu, 0.0 io}, id = 13

at 
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:117)
at 
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:112)
at 
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1171)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:326)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
at 
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:666)
at 
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:519)
...
Suppressed: java.lang.ArithmeticException: Value 216000 out of range
at 
org.apache.calcite.linq4j.tree.Primitive.checkRoundedRange(Primitive.java:383)
at 
org.apache.calcite.linq4j.tree.Primitive.numberValue(Primitive.java:412)
at 
org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:575)
at 
org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:305)
at 
org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:39)
at 
org.apache.calcite.linq4j.tree.BinaryExpression.accept(BinaryExpression.java:47)
{code}

This seems to happen because the implementation insists in evaluating the 
expression by converting the 25 days interval to milliseconds, which overflows. 
However, adding a days interval to a time should be a noop. Replacing 'days' 
with 'months', for example, works fine.



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

Re: [DISCUSS] Towards Calcite 1.37.0

[Stamatis Zampetakis]

I agree with others that we shouldn't wait too long for cutting a
release. I am pretty sure there are many good PRs that can be merged
but nobody prevents us from making another release once this is done.
Having an RC on Monday would be great.

For people who may be completely familiar with all our
processes/tools, I outline below two points that are somewhat relevant
to the discussion so far.

In general we don't have a strict review-then-commit (RTC) policy for
merging changes in Calcite. In various cases committers of the project
can merge changes without getting an explicit approval. This shouldn't
happen for risky or debatable patches but it is fine to do that for
addressing small bugs, minor improvements, etc. It's up to the
discretion of the committer to decide when to merge a change.

All JIRA activities (conversations, updates, etc.) can be tracked by
subscribing to the issues@calcite list. People who are subscribed to
issues@ receive notifications for every JIRA ticket even if they are
not following a particular ticket.

Best,
Stamatis


On Thu, Apr 18, 2024 at 9:29 PM Sergey Nuyanzin  wrote:
>
> Thanks Benchao and Francis for pushing
> you are right we need to finally make an RC
>
> Thanks Mihai for driving this work
> Starting tomorrow I will have more time which I can use to help with
> review.
> I would suggest to set a deadline like end of Saturday/begin of Sunday
> in order to have an RC on Monday (IIRC anyway because of holidays voting
> period was usually extended)
>
> WDYT?
>
>
>
>
> On Thu, Apr 18, 2024 at 6:55 PM Mihai Budiu  wrote:
>
> > I have a few PR that I would like to land in 1.37 which have received no
> > reviews.
> > Three of them resolve bugs which I consider quite important.
> > Let me describe them briefly, maybe this will help convince someone to
> > contribute the effort of reviewing.
> > Normally this kind of discussion is made inside of JIRA, but I noticed
> > that if one is not following a particular JIRA ticket, they will never see
> > the conversation.
> >
> > [CALCITE-6322] Casts to DECIMAL types are ignored<
> > https://github.com/apache/calcite/pull/3733>
> >
> > Code like (CAST x AS DECIMAL(5, 2)) is treated by Calcite like a NOOP. I
> > consider this as a major bug, which has been open for a very long time.
> > This PR handles the cases where X is a numeric type.
> >
> > [CALCITE-2067] RexLiteral cannot represent accurately floating point
> > values, including NaN, Infinity<
> > https://github.com/apache/calcite/pull/3663>
> >
> > Calcite uses BigDecimal values to represent floating point literals. This
> > has two problems:
> >
> >   *
> > some FP constants cannot be represented exactly, leading to subtle
> > rounding errors in computations that are performed at compilation-time
> >   *
> > FP literals cannot represent special FP values, like NaN
> >
> > This PR switches the representation of FP literals to use Java
> > Double/Float values. This is a breaking change, because it changes the
> > semantics of some programs. However, I claim that these programs were
> > initially incorrect.
> >
> > [CALCITE-3522] Sql validator limits decimal literals to 64 bits and
> > [CALCITE-6169] EnumUtils.convert does not implement the correct SQL cast
> > semantics
> >
> > This PR solves two problems at once. I initially started by solving 3522,
> > but then I realized that the solution uncovers many bugs in 6169, so I
> > solved that one as well. Just days ago someone filed
> > https://issues.apache.org/jira/browse/CALCITE-6366 for this very issue.
> >
> >
> >   *
> > 3522 solves the problem where Calcite limits DECIMAL literals to 64 bits.
> > However, even the default DECIMAL implementation in Calcite supports 128
> > bits, and some SQL dialects go even further (Postgres has billions of
> > digits of precision). With this change there are no limits to the precision
> > of a DECIMAL literal, and the limits come from the Calcite typeSystem in
> > use.
> >   *
> > 6366 solves another problem related to the first issue described above,
> > 6322, where narrowing casts (that convert a numeric value to a numeric
> > value with fewer bits) do not report errors on overflow. This is another
> > long-standing bug in Calcite.
> >
> > I will try to break this into two separate PRs that have to be merged in
> > order; I will start with 6169. Maybe this will make it more palatable for
> > the reviewers.
> >
> > Besides these 3 PRs, I have one more PR that I would like to land in 1.37,
> > which is not a bugfix, but a new feature, so perhaps it's less urgent.
> > [CALCITE-6071] RexCall should carry source position information for runtime
> > error reporting is a
> > relatively large PR, which adds source position information to RexCall and
> > AggregateCall nodes. This is useful when a runtime error happens, like a
> > division by 0. Using this information the runtime can report which
> > division 

[jira] [Created] (CALCITE-6376) Filtering CTE of at least 6 columns with QUALIFY operation results in exception

[Austin Richardson (Jira)]

Austin Richardson created CALCITE-6376:
--

 Summary: Filtering CTE of at least 6 columns with QUALIFY 
operation results in exception
 Key: CALCITE-6376
 URL: https://issues.apache.org/jira/browse/CALCITE-6376
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.36.0
Reporter: Austin Richardson


Example query:

 
{code:java}
WITH MyCTE AS (
SELECT 
column1,
column2,
column3,
column4,
column5,
column6
FROM (
VALUES 
('value1', 10, 5.0, 'data1', 'info1', 'test1'),
('value2', 20, 4.0, 'data2', 'info2', 'test2'),
('value3', 30, 3.0, 'data3', 'info3', 'test3'),
('value4', 40, 2.0, 'data4', 'info4', 'test4'),
('value5', 50, 1.0, 'data5', 'info5', 'test5')
) AS t(column1, column2, column3, column4, column5, column6)
)
SELECT *
FROM MyCTE
QUALIFY RANK() OVER (ORDER BY column3) = 1{code}
 

Either removing one of the columns or the QUALIFY filter results in a 
successful query.



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