Gábor E. Gévay
Gábor E. Gévay
Thanks, I've added this in the issue description.
Thx, added a link to your comment to the issue description.
Newer Slack thread on `Datum::Error`: https://materializeinc.slack.com/archives/C077FUD1F9C/p1718287744657919?thread_ts=1718221293.477699&cid=C077FUD1F9C
[Idea](https://materializeinc.slack.com/archives/C077FUD1F9C/p1718351117653859?thread_ts=1718221293.477699&cid=C077FUD1F9C) for how we could even keep error behavior unchanged across any reorderings: - For any expression that could error (an "error source"), we'd assign an "error source id" before...
> > * When optimization moves stuff around, the error source ids would move around with the expressions. E.g., every MirScalarExpr node would have an additional field that records the...
Hmm, I'm not really sure what is happening in this query. > constant folding seems to prioritize the WHERE condition in contrast to data-flow rendering, which potentially evaluates the JOIN...
Ah, sorry, you are right, I missed the error msg somehow. But I still have no idea how can this happen. I'd expect that the full outer join has to...
(Currently blocked by the need to record query plans in the catalog.)
Yes, https://github.com/MaterializeInc/materialize/issues/20660 would be one way to unblock this. However, I'm thinking that instead we might want to build on @aalexandrov's work that will add query plans to the catalog...
>> We'd have to skip through a lot of one-off queries, which are irrelevant for this issue > Why is this? Not following. Sorry, maybe I didn't make it clear...