public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Richard Guo <[email protected]>
Cc: Eric Ridge <[email protected]>
Cc: Pg Hackers <[email protected]>
Subject: Re: Fwd: pg18 bug? SELECT query doesn't work
Date: Wed, 07 Jan 2026 12:00:42 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAMbWs48nfVij2BuU=3cJhRLVpvEc6krW5erG-hTcTRk673i7TQ@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CAMbWs49jxSN3AQ0xc9=Cyx8OgLbzu9su6QK68zKgZCsQxTk68w@mail.gmail.com>
<CAMbWs49jgcUS1yowhmDrsY-yDurniYSQWL_RpD8gPjKsah4fpw@mail.gmail.com>
<[email protected]>
<CAMbWs48nfVij2BuU=3cJhRLVpvEc6krW5erG-hTcTRk673i7TQ@mail.gmail.com>
Richard Guo <[email protected]> writes:
> On Wed, Jan 7, 2026 at 11:37 AM Tom Lane <[email protected]> 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
view thread (8+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Fwd: pg18 bug? SELECT query doesn't work
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox