Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r0x0q-008YWi-0r for pgsql-bugs@arkaria.postgresql.org; Thu, 09 Nov 2023 04:51:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1r0x0o-00B0BU-8b for pgsql-bugs@arkaria.postgresql.org; Thu, 09 Nov 2023 04:51:26 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r0x0n-00B0BM-S4 for pgsql-bugs@lists.postgresql.org; Thu, 09 Nov 2023 04:51:26 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r0x0k-004gT2-Pm for pgsql-bugs@lists.postgresql.org; Thu, 09 Nov 2023 04:51:24 +0000 Received: from [192.168.1.113] (unknown [103.206.205.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: a.lepikhov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id BE3EEE20FBE; Thu, 9 Nov 2023 07:51:17 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1699505479; bh=iVP4CGEq5AMdNyjHk+3OmCuzQ3jJpr5ur8cw30rngrw=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=6Q8psvtCU/L18sy4QXNKcIjU5RmxCOqgeWmSbRaq776tsU2pooUTwnPxZR0vLHQii 5XDJbm6wJCa5tLUBrZNMx3OMgJ3tkskdluobQN133tvDqwBF+149cnhXXJFDOuiwJ+ D0bEE3mh0WcMXQHms8qOcqVOqnKK2lkGws2XGwr9Bun2ppLO36lat3792tZRnRm7CP 5eX+vYCvXiZit97Nw6hhxiBiVs47nyStQ8jWyJkAPZW96b2UX7lbuIN3B0jZcut6nP WGAohkjrh3N6i2X8fDN8uJ4OabL/AwHNSNDneqKF7QHpo5y9o8H06q6gijQ/H88diY m8letjnPL5lsg== Message-ID: Date: Thu, 9 Nov 2023 11:51:14 +0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN To: Richard Guo Cc: zuming.jiang@inf.ethz.ch, pgsql-bugs@lists.postgresql.org, PG Bug reporting form References: <18187-831da249cbd2ff8e@postgresql.org> <491881ef-f1c7-4a86-b5dd-dcad55a88ab4@postgrespro.ru> Content-Language: en-US From: Andrei Lepikhov Organization: Postgres Professional In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 9/11/2023 10:54, Richard Guo wrote: > > On Wed, Nov 8, 2023 at 11:42 PM Andrei Lepikhov > > wrote: > > The issue looks like previous one, related to new SJE feature. > > Reduced case: > CREATE TABLE t2 (vkey int4, c9 text, primary key(vkey)); > SELECT * FROM ( >    SELECT CASE WHEN '1' = ref_0.c9 THEN 1 ELSE 1 END AS c_3 > FROM t2 as ref_0 >    JOIN t2 AS ref_1 >    ON ref_0.vkey = ref_1.vkey >      RIGHT OUTER JOIN t2 AS ref_2 >      ON ref_1.vkey = ref_2.vkey) AS t5 >    RIGHT OUTER JOIN (SELECT 1 AS c_2) AS t4 >    ON t4.c_2 IS NOT NULL; > > The key problem lies in the 'CASE' statement. > > > I've looked into this a little bit.  I think it's caused by the SJE > logic not properly removing references from PHVs.  Specifically, it > fails to replace the ref_0's Vars within phv->phexpr, leading them to be > added in ref_2/ref_1 join's targetlist. > > Also, I noticed that in remove_rel_from_query() we perform replace_relid > for phv->phrels twice at line 475 and 478, which seems not right to me. > >  475   phv->phrels = replace_relid(phv->phrels, relid, subst); >  476   phv->phrels = replace_relid(phv->phrels, ojrelid, subst); >  477   phinfo->ph_lateral = replace_relid(phinfo->ph_lateral, relid, > subst); >  478   phinfo->ph_var->phrels = replace_relid(phinfo->ph_var->phrels, > relid, subst); Thanks a lot! Your patch looks correct. We really have been missing replacing the PlaceHolderVar expression references for all the development time. The test in join.sql works correctly. Should we add a reference to the bug that triggered the issue as a comment to the test? Also, to be sure, maybe add column t4.code into the list of the coalesce parameters? -- regards, Andrei Lepikhov Postgres Professional