On Mon, Apr 7, 2025 at 9:54 PM Andrei Lepikhov <lepi...@gmail.com> wrote: > 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 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. Do you mean this check is designed to work in conjunction with the clause_sides_match_join check in paraminfo_get_equal_hashops? I would consider this a very poor design. The purpose of this check is simply to verify whether all restriction clauses are parameterized. I don't understand why it needs to depend on paraminfo_get_equal_hashops in such an unexpected way to function correctly. I can't see any advantage to this design, other than that it's prone to bugs. Moreover, in the case where not all restriction clauses are parameterized, why waste CPU cycles running all the code after the check only for paraminfo_get_equal_hashops to catch it later? Additionally, I couldn't find any comments explaining this unusual behavior, either in the check itself or in paraminfo_get_equal_hashops. Thanks Richard
