calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Date Wed, 05 Jun 2019 21:09:14 GMT
My instinct is that we should leave it unexpanded. And that we should recognize “equals-like
operators”, so that a planner rule originally written for ‘=‘ could easily be expanded
to also apply to ‘is not distinct from’.

Of course there would be a way of expanding it that we could use if circumstances required
it — e.g. if sending SQL to a database that does not understand IS NOT DISTINCT FROM —
but we would not expand it by default.

If both arguments are not null, it probably makes sense to rewrite “x IS NOT DISTINCT FROM
y” to “x = y”, because the latter is more common and no less simple.


> On Jun 5, 2019, at 1:46 PM, Haisheng Yuan <> wrote:
> I see INDF is rewritten to OR, and FilterRemoveIsNotDistinctFromRule rewrites INDF to
CASE expression. Why do we want to do that? To simplify expression like "a is not distinct
from b or a = b"? Then we spend a lot effort to convert OR/CASE back to INDF. 
> I am curious what is the motivation to rewrite INDF. Does it really help a lot in production?
I would like to hear the use cases if it does.
> - Haisheng

View raw message