On 4/7/25 09:50, Richard Guo wrote:
> Consider the join to t3. It is a unique join, and not all of its
> restriction clauses are parameterized. Despite this, the check still
> passes.
At least, this code looks more simple to understand, more 'armored' and
worth to change.
At the same time I think term 'Incorrect' is not good unless you show an
example where data returned is not consistent to the expected.
I think this inequality check has worked in couple with the
get_equal_hashops.
I think it may be pushed as is. But it worth to discover the
get_equal_hashops more deeply. Discovering your idea I wrote an example
(see attachment) which (with commented clause_sides_match_join) provides
an incorrect Memoize - that's why I ended up with support of your change
even when you can't show any buggy behaviour. But I've got an assertion
that is different from the error I expected to see (error on single_row
mode):
#0 0x00005583c45532ce in CheckVarSlotCompatibility
#1 0x00005583c4553244 in CheckExprStillValid
#2 0x00005583c45530ea in ExecInterpExprStillValid
#3 0x00005583c45a245c in ExecEvalExpr
#4 0x00005583c45a3985 in prepare_probe_slot
#5 0x00005583c45a3e52 in cache_lookup
#6 0x00005583c45a4313 in ExecMemoize
It looks strange.
--
regards, Andrei Lepikhov
