MIME-Version: 1.0
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>
In-Reply-To: <1654153.1767753474@sss.pgh.pa.us>
From: Richard Guo <guofenglinux@gmail.com>
Date: Wed, 7 Jan 2026 16:31:27 +0900
Message-ID: <CAMbWs48nfVij2BuU=3cJhRLVpvEc6krW5erG-hTcTRk673i7TQ@mail.gmail.com>
Subject: Re: Fwd: pg18 bug? SELECT query doesn't work
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Eric Ridge <eebbrr@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAMbWs48nfVij2BuU%3D3cJhRLVpvEc6krW5erG-hTcTRk673i7TQ%40mail.gmail.com>
Precedence: bulk

On Wed, Jan 7, 2026 at 11:37=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Richard Guo <guofenglinux@gmail.com> writes:
> > (I wonder whether this same issue exists for join alias Vars.)

> Seems highly likely that we'd have noticed if it did.  I think
> flatten_join_alias_vars happens early enough that no interesting
> decisions have been made yet.  I wonder whether we could fix the
> current problem by doing grouping-Var expansion earlier?

Hmm, I don't think so.  The decision on whether to push down a
subquery's restriction clauses is made even before we invoke
subquery_planner() on that subquery.  At that stage, join alias Vars
have not yet been flattened, meaning the underlying expressions are
still hidden.  What I was wondering is whether this could cause
subquery_is_pushdown_safe() to make the wrong decision.

For the same reason, it seems that doing grouping-Var expansion
earlier wouldn't help with this bug, unless we move that expansion
ahead of the subquery_planner() call entirely.

In addition, it seems to me that it would cause problems if we move
the expansion of grouped Vars to before we've done with expression
preprocessing on targetlist and havingQual.  For example, consider
this query:

    select not a from t group by rollup(not a) having not not a;

If we do grouping-Var expansion before the havingQual is preprocessed,
the HAVING clause "not not a" would be reduced to "a" and thus fail to
be matched to lower tlist.

> 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.  I ran a simple test with named args in function
calls:

create table t (i int);

CREATE OR REPLACE FUNCTION add_three(
    a int DEFAULT 0,
    b int DEFAULT 0,
    c int DEFAULT 0
)
RETURNS int AS $$
    SELECT a + b + c;
$$ LANGUAGE sql;

explain (verbose, costs off)
select add_three(i, c =3D> 10) from t group by 1 having add_three(i, c
=3D> 10) > 100;
                QUERY PLAN
------------------------------------------
 HashAggregate
   Output: (((i + 0) + 10))
   Group Key: ((t.i + 0) + 10)
   ->  Seq Scan on public.t
         Output: ((i + 0) + 10)
         Filter: (((t.i + 0) + 10) > 100)
(6 rows)

... and the named args are expanded as expected.

- Richard