Re: An incorrect check in get_memoize_path - Mailing list pgsql-hackers

On Mon, Apr 7, 2025 at 9:54 PM Andrei Lepikhov <lepihov@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