Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pVHZb-00069C-4J for pgsql-bugs@arkaria.postgresql.org; Thu, 23 Feb 2023 19:48:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pVHZa-0000ih-0M for pgsql-bugs@arkaria.postgresql.org; Thu, 23 Feb 2023 19:48:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pVHZZ-0000iF-OM for pgsql-bugs@lists.postgresql.org; Thu, 23 Feb 2023 19:48:09 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pVHZX-0001RC-Iv for pgsql-bugs@lists.postgresql.org; Thu, 23 Feb 2023 19:48:08 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 31NJm5ER598429; Thu, 23 Feb 2023 14:48:05 -0500 From: Tom Lane To: Richard Guo cc: Andrey Lepikhov , PostgreSQL mailing lists Subject: Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware) In-reply-to: References: <0b819232-4b50-f245-1c7d-c8c61bf41827@postgrespro.ru> Comments: In-reply-to Richard Guo message dated "Wed, 22 Feb 2023 18:24:11 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <598427.1677181685.1@sss.pgh.pa.us> Date: Thu, 23 Feb 2023 14:48:05 -0500 Message-ID: <598428.1677181685@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > ISTM that for outer join identity 3, if we are given form > (A leftjoin B on (Pab)) leftjoin C on (Pbc) > then references to C Vars in higher qual levels would be marked with the > B/C join. If we've transformed it to form > A leftjoin (B leftjoin C on (Pbc)) on (Pab) > then references to C Vars in higher qual levels should be adjusted to > include both B/C join and A/B join in their varnullingrels. Hmm. I remember having convinced myself that we didn't need to change anything above the commuting OJs, but now I can't reconstruct the reasoning :-(. I wonder whether we could instead fix things by deeming that the result of the pushed-down B/C join does not yet produce correct C* variables, so that we won't allow conditions involving them to drop below the pushed-up A/B join. This would be a little bit messy in some places because now we'd consider that the A/B join is adding two OJ relids not just one to the output join relid set, while the B/C join is adding no relids even though it must execute an outer join. (But we already have that notion for semijoins and some antijoins, so maybe it's fine.) regards, tom lane