Re: Query result differences between PostgreSQL 17 vs 16

Richard Guo <guofenglinux@gmail.com> writes:
>> On Wed, Feb 26, 2025 at 3:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Thanks for that.  The code and comment added to
>>> restriction_is_always_true look good, but I can't help wondering
>>> whether we don't need the same in restriction_is_always_false.

> After some attempts, I failed to find such a query.  An IS NULL qual
> is not strict, and it makes the outer join not commutable with other
> joins per outer-join identity 3.  We could add another strict qual to
> the join clauses to make the outer join commutable.  However, in this
> case whether we reduce the IS NULL qual to a constant false would not
> affect the join outputs, due to the strict qual.

> I'm starting to believe that reducing an IS NULL clone clause to a
> constant false should be safe.  Any thoughts?

Not sure.  I think the risk factor here is fooling the clone-clause
mechanisms by failing to install some clone of an original outer
join clause in a rel's restriction list.  Looking at the callers
of restriction_is_always_false:

add_base_clause_to_rel
add_join_clause_to_rels

    These two replace the clause with a Const "false" that is
    marked with the same rinfo_serial.  Therefore the expectation
    that every group of clones will have a representative is
    still satisfied, even though the representative doesn't
    contain quite what you might expect.

apply_child_basequals

    This just summarily rejects the child rel as not needing
    to be built.  I think that might be okay, since we don't
    really make any further deductions with an appendrel
    child's quals.

I've not actually worked through the bug case to verify my hypothesis
that it's the lack of a representative for a clone group that is
breaking things.  (Maybe you did?)  But if that is the direct
cause of the failure, then it's plausible that none of these
callers are subject to it.

I'm a bit inclined to argue that we should put in the no-clone-quals
limitation anyway, to protect future callers that might not manage
to dodge the problem.  OTOH, if we get rid of these functions
altogether as I expressed my desire to do nearby, it's all moot.

            regards, tom lane