Content-Type: multipart/mixed; boundary="------------0OpaIW5Q4ecghJND0MCyYshF"
Message-ID: <a78fe5d4-e6b8-4b3c-9cfd-135edbb68e4c@gmail.com>
Date: Wed, 18 Mar 2026 13:18:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19435: Error: "No relation entry for relid 2" Triggered by
 Complex Join with Self-Referencing Tables
To: Alexander Korotkov <aekorotkov@gmail.com>,
 Tender Wang <tndrwang@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>,
 Fujii Masao <masao.fujii@gmail.com>, ammmkilo@163.com,
 pgsql-bugs@lists.postgresql.org
References: <19435-3cc1a87f291129f1@postgresql.org>
 <CAHGQGwEEHFnH8DsZbwxdZeiHozm2LCRTLSgL8Qn=5MoN4450ZA@mail.gmail.com>
 <CAPpHfdsDQhDqvqi+-UxvyYRP72ASkdWzCn43e2Hj6WsY15opvA@mail.gmail.com>
 <CAHewXNmU3E0oXLgvoOtXw7kfTiAZsKu8La_hQ=pyScgxvP45iw@mail.gmail.com>
 <CAHewXN=LjuWz3PcyhjdbJAyo+Zs9MisPDRYnSZBUy4PMeKi+zA@mail.gmail.com>
 <CALdSSPj1kTTQvmV3H3HMf5P3um8ybxoH3DaTPm+XgdYAur1Q4A@mail.gmail.com>
 <CAHewXNndByMu3S+_h4LLDkXA5qrO1s=s-CE8HqUtc9vTA9yrjg@mail.gmail.com>
 <CAPpHfdv6gzSTXHJxYSgB8sULadXM4wvhgoQODaOxYCJfagKNPw@mail.gmail.com>
 <CAHewXN=7kDJjUcgEm+6qhaKOXuqzvhRqAAKdafNCRgn0yH7BGg@mail.gmail.com>
 <CAHewXNm5OOREJ8wZ1cLJdQz7O1aQ0E1RBB55S6O138K8vBdc9g@mail.gmail.com>
 <CAPpHfducqLJ=o3LkoPKGfZJVQuuei+P=2oUF6hX6rzHTZSxoyA@mail.gmail.com>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <CAPpHfducqLJ=o3LkoPKGfZJVQuuei+P=2oUF6hX6rzHTZSxoyA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/a78fe5d4-e6b8-4b3c-9cfd-135edbb68e4c%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------0OpaIW5Q4ecghJND0MCyYshF
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 18/3/26 09:40, Alexander Korotkov wrote:
> What about being more generic and call ChangeVarNodes_walker() for the
> node in ChangeVarNodesWalkExpression()?  It also works with out case
> and avoids code duplication.
I’ve reached the same conclusion. We lost a possible case when the 
RestrictInfo→clause contains a bare Var that isn’t pushed into either 
the left or right subtree.
I think we can fix this by replacing the expression walker with 
ChangeVarNodes_walker().
What is the reason for the second change? Tender, can you show us how to 
reproduce the issue so we can support your update to 
restrict_infos_logically_equal? If we include it, we should add a test.

-- 
regards, Andrei Lepikhov,
pgEdge
--------------0OpaIW5Q4ecghJND0MCyYshF
Content-Type: text/plain; charset=UTF-8; name="fix.diff"
Content-Disposition: attachment; filename="fix.diff"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3Jld3JpdGUvcmV3cml0ZU1hbmlwLmMgYi9zcmMv
YmFja2VuZC9yZXdyaXRlL3Jld3JpdGVNYW5pcC5jCmluZGV4IGZlODk3NTRhNzNjLi42MTBl
ZGYxMDI4NCAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvcmV3cml0ZS9yZXdyaXRlTWFuaXAu
YworKysgYi9zcmMvYmFja2VuZC9yZXdyaXRlL3Jld3JpdGVNYW5pcC5jCkBAIC03NDQsOSAr
NzQ0LDcgQEAgQ2hhbmdlVmFyTm9kZXMoTm9kZSAqbm9kZSwgaW50IHJ0X2luZGV4LCBpbnQg
bmV3X2luZGV4LCBpbnQgc3VibGV2ZWxzX3VwKQogYm9vbAogQ2hhbmdlVmFyTm9kZXNXYWxr
RXhwcmVzc2lvbihOb2RlICpub2RlLCBDaGFuZ2VWYXJOb2Rlc19jb250ZXh0ICpjb250ZXh0
KQogewotCXJldHVybiBleHByZXNzaW9uX3RyZWVfd2Fsa2VyKG5vZGUsCi0JCQkJCQkJCSAg
Q2hhbmdlVmFyTm9kZXNfd2Fsa2VyLAotCQkJCQkJCQkgICh2b2lkICopIGNvbnRleHQpOwor
CXJldHVybiBDaGFuZ2VWYXJOb2Rlc193YWxrZXIobm9kZSwgY29udGV4dCk7CiB9CiAKIC8q
Cg==

--------------0OpaIW5Q4ecghJND0MCyYshF--