You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dev=> create table t (a int);
CREATE_TABLE
dev=> insert into t values (4), (9);
INSERT 0 2
dev=> create materialized view mv1 as select a / 0 as z from t;
CREATE_MATERIALIZED_VIEW
dev=> select * from mv;
z
---
(2 rows)
dev=> create materialized view mv2 as select 3 / 0 as z from t;
ERROR: Failed to run the query
Caused by these errors (recent errors listed first):
1: Expr error
2: error while evaluating expression `general_div('3', '0')`
3: Division by zero
The first mv fills null on each input row, while the second mv detects the constant error. This makes sense.
However, when the underlying source is the newly introduced generate_series(..., now(), ...):
dev=> create materialized view mv3 as select extract(epoch from t) / 0 as z from generate_series('2024-01-01'::timestamptz, now(), interval '1' month) as s(t);
NOTICE: Your session timezone is UTC. It was used in the interpretation of timestamps and dates in your query. If this is unintended, change your timezone to match that of your data's with `set timezone = [timezone]` or rewrite your query with an explicit timezone conversion, e.g. with `AT TIME ZONE`.
CREATE_MATERIALIZED_VIEW
dev=> select * from mv;
z
---
(6 rows)
dev=> create materialized view mv as select 3 / 0 as z from generate_series('2024-01-01'::timestamptz, now(), interval '1' month);
NOTICE: Your session timezone is UTC. It was used in the interpretation of timestamps and dates in your query. If this is unintended, change your timezone to match that of your data's with `set timezone = [timezone]` or rewrite your query with an explicit timezone conversion, e.g. with `AT TIME ZONE`.
CREATE_MATERIALIZED_VIEW
dev=> select * from mv;
z
---
(0 rows)
In the former case, it fills null same as table above. But in the latter constant case, no error was returned and no rows with nulls are updated into the mv.
Error message/log
No response
To Reproduce
See description above.
Expected behavior
Either an immediate error, or 6 rows with null.
How did you deploy RisingWave?
No response
The version of RisingWave
No response
Additional context
Inspired by #17461: after the column pruning fix, a constant error date 't' leads to an empty mv rather than an error or mv with 6 rows of nulls.
The text was updated successfully, but these errors were encountered:
Describe the bug
When the underlying source is a table:
The first mv fills
null
on each input row, while the second mv detects the constant error. This makes sense.However, when the underlying source is the newly introduced
generate_series(..., now(), ...)
:In the former case, it fills
null
same as table above. But in the latter constant case, no error was returned and no rows withnull
s are updated into the mv.Error message/log
No response
To Reproduce
See description above.
Expected behavior
Either an immediate error, or 6 rows with
null
.How did you deploy RisingWave?
No response
The version of RisingWave
No response
Additional context
Inspired by #17461: after the column pruning fix, a constant error
date 't'
leads to an empty mv rather than an error or mv with 6 rows ofnull
s.The text was updated successfully, but these errors were encountered: