Content-Type: multipart/alternative;
 boundary="------------TANvO0oUGfqzFszZ0ANe4P8d"
Message-ID: <6072cd36-8d7b-457a-a7c6-7cf41c05fe6c@gmail.com>
Date: Sat, 28 Jun 2025 09:00:01 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #18953: Planner fails to build plan for complex query with
 LATERAL references
To: Tom Lane <tgl@sss.pgh.pa.us>, Richard Guo <guofenglinux@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
References: <18953-1c9883a9d4afeb30@postgresql.org>
 <CAMbWs49XTfPD9OCw9xWsRtbiNYgQ-Nau_hHy9UbbGP-w2V=ANQ@mail.gmail.com>
 <1268645.1749765012@sss.pgh.pa.us> <1499514.1749848324@sss.pgh.pa.us>
 <CAMbWs4_E7wC3LX17jr+RnRunz9ROcwhn0eXt0riJ6FjbxB0g+g@mail.gmail.com>
 <527134.1750087495@sss.pgh.pa.us>
 <CAMbWs4_wYvQWHCwBfSXj9OQ-fWn+xnntR+EVzks2KB0eRWcRpw@mail.gmail.com>
 <835659.1750177751@sss.pgh.pa.us>
 <837b0dce-b2f3-4811-bccf-f42e8985d6e2@gmail.com>
 <3040798.1750617116@sss.pgh.pa.us> <3886446.1750703041@sss.pgh.pa.us>
 <afb7be67-cc8a-42b9-952a-0bd7e8c9f925@gmail.com>
 <1487176.1750963077@sss.pgh.pa.us>
 <CAMbWs4_iW1e5ciQN1U7a8Nz773D5cV3p6UrL2zeXrbhoqzr=iw@mail.gmail.com>
 <2056150.1751049350@sss.pgh.pa.us> <2075249.1751060239@sss.pgh.pa.us>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <2075249.1751060239@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/6072cd36-8d7b-457a-a7c6-7cf41c05fe6c%40gmail.com>
Precedence: bulk

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

Hello Tom and Richard,

28.06.2025 00:37, Tom Lane wrote:
> ... BTW, looking at these two patches again, I wonder if it'd be
> better to put the hackery for SubLink conversion into
> identify_current_nestloop_params?  That'd remove the need to argue
> that we don't have to fix both copies of a nestloop-parameter PHV.
> The responsibility doesn't clearly belong to
> identify_current_nestloop_params, but it doesn't clearly belong
> to create_nestloop_plan either, so neither choice seems superior
> from a modularity standpoint.

I've discovered a query which fails with an error after a16ef313f with
both v2 patches applied:
create temp table t(i int primary key);
select * from
     (select k from
         (select i, coalesce(i, j) as k from
             (select i from t union all select 1)
             join (select 1 as j limit 1) on i = j)
         right join (select 1) on true
         join (select 1) on i is not null
     ),
     lateral (select k offset 1);
ERROR:  XX000: variable not found in subplan target list
LOCATION:  fix_upper_expr_mutator, setrefs.c:3310

Thank you for working on this!

Best regards,
Alexander
--------------TANvO0oUGfqzFszZ0ANe4P8d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Tom and Richard,<br>
      <br>
      28.06.2025 00:37, Tom Lane wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:2075249.1751060239@sss.pgh.pa.us">
      <pre wrap="" class="moz-quote-pre">... BTW, looking at these two patches again, I wonder if it'd be
better to put the hackery for SubLink conversion into
identify_current_nestloop_params?  That'd remove the need to argue
that we don't have to fix both copies of a nestloop-parameter PHV.
The responsibility doesn't clearly belong to
identify_current_nestloop_params, but it doesn't clearly belong
to create_nestloop_plan either, so neither choice seems superior
from a modularity standpoint.
</pre>
    </blockquote>
    <br>
    I've discovered a query which fails with an error after a16ef313f
    with<br>
    both v2 patches applied:<br>
    create temp table t(i int primary key);<br>
    select * from<br>
        (select k from<br>
            (select i, coalesce(i, j) as k from<br>
                (select i from t union all select 1)<br>
                join (select 1 as j limit 1) on i = j)<br>
            right join (select 1) on true<br>
            join (select 1) on i is not null<br>
        ),<br>
        lateral (select k offset 1);<br>
    ERROR:  XX000: variable not found in subplan target list<br>
    LOCATION:  fix_upper_expr_mutator, setrefs.c:3310<br>
    <br>
    Thank you for working on this!<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------TANvO0oUGfqzFszZ0ANe4P8d--