From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: Eric Ridge <eebbrr@gmail.com>,
        Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Fwd: pg18 bug? SELECT query doesn't work
In-reply-to: <CAMbWs48nfVij2BuU=3cJhRLVpvEc6krW5erG-hTcTRk673i7TQ@mail.gmail.com>
References: <7900964C-F99E-481E-BEE5-4338774CEB9F@gmail.com> <C7FCAD3A-9859-4CCB-95DE-62ECF1368331@gmail.com> <1607957.1767725532@sss.pgh.pa.us> <CAMbWs49jxSN3AQ0xc9=Cyx8OgLbzu9su6QK68zKgZCsQxTk68w@mail.gmail.com> <CAMbWs49jgcUS1yowhmDrsY-yDurniYSQWL_RpD8gPjKsah4fpw@mail.gmail.com> <1654153.1767753474@sss.pgh.pa.us> <CAMbWs48nfVij2BuU=3cJhRLVpvEc6krW5erG-hTcTRk673i7TQ@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Wed, 07 Jan 2026 16:31:27 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1752323.1767805242.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Wed, 07 Jan 2026 12:00:42 -0500
Message-ID: <1752324.1767805242@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1752324.1767805242%40sss.pgh.pa.us>
Precedence: bulk

Richard Guo <guofenglinux@gmail.com> writes:
> On Wed, Jan 7, 2026 at 11:37 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm also wondering (don't recall the details of your patch)
>> whether you are repeating eval_const_expressions after
>> grouping-Var expansion.  If not, there are going to be bugs
>> there, like failure to handle named args in function calls.
>> That could be another reason to make this happen earlier.

> Currently we're not repeating eval_const_expressions after the
> grouping-Var expansion, but I fail to wrap my head around why that
> would be a problem.

What I was mainly concerned about was whether the replacement
expressions ever got passed through eval_const_expressions().
I see now that they do, at planner.c:1069.

It's still not really desirable that this is done separately;
for example, I think it breaks the assumption that we will have
AND/OR flatness everywhere.  But I think that only leads to
possible inefficiencies not wrong answers.  And I do take your
point about needing to preserve the separate identities of
these subexpressions.  So let's let that go for now.

The main problem, as you say, is that allpaths.c is coming to
conclusions about the contents of output expressions of the
subquery without having done any of this.  The only really
simple answer I can see is to make a copy of the subquery's
tlist and apply these transformations to it before we run
the subquery_is_pushdown_safe logic.  That's ... ugly.

Perhaps another idea could be to shove the responsibility for this
down into subquery_planner (or make it call a callback at the right
point), and handle transferring of parent restriction clauses into
HAVING only after we've finished preprocessing the subquery's tlist.
That's an uncomfortably big change to be making in a released branch,
but it might still be a better way than duplicating preprocessing.

			regards, tom lane