Re: An incorrect check in get_memoize_path

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