Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN

Поиск
Список
Период
Сортировка
От Andrei Lepikhov
Тема Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN
Дата
Msg-id e6cecb71-1b3c-4fba-826a-f176bc3639be@postgrespro.ru
обсуждение исходный текст
Ответ на Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN  (Richard Guo <guofenglinux@gmail.com>)
Ответы Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN  (Richard Guo <guofenglinux@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [BUGS] \copy produces CSV output that cannot be read by \copy
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18209: New connection is waiting for ProcArrayLock lock when execute a stored procedure concurrently