Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN - Mailing list pgsql-bugs

From Andrei Lepikhov
Subject Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN
Date
Msg-id e6cecb71-1b3c-4fba-826a-f176bc3639be@postgrespro.ru
Whole thread Raw
In response to Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-bugs
On 20/11/2023 15:49, Richard Guo wrote:
>     I'm wondering if we can relax this restriction because it seems to me
>     that a PHV evaluated/needed at or below the self join should not have
>     problem if we remove the self join.
> 
> 
> After some more thought, I think PHVs should not impose any constraints
> on removing self joins.  If the removed rel is contained in the relids
> that a PHV is evaluated/needed at or laterally references, it can just
> be replaced with the rel that is kept.
> 
> Attached is a patch to remove such constraints.  Any comments or
> feedback are welcome.

Carrying out excavations, I found that it was Teodor Sigaev who added 
this limitation in v.20 of the patch in an earlier stage of the development.
I also had analyzed this part of code and came to the conclusion that it 
doesn't needed. Only a paranoid approach and the absence of an 
alternative opinion are the reasons why this code is still exists.
Your patch is ok.
I think the comment, 'PHVs should not impose ...' looks redundant. It 
may be enough to have it in the commit comment.

-- 
regards,
Andrei Lepikhov
Postgres Professional




pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [BUGS] \copy produces CSV output that cannot be read by \copy
Next
From: PG Bug reporting form
Date:
Subject: BUG #18209: New connection is waiting for ProcArrayLock lock when execute a stored procedure concurrently