Re: Fwd: pg18 bug? SELECT query doesn't work

Richard Guo <guofenglinux@gmail.com> writes:
> On Wed, Jan 7, 2026 at 3:52 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I've not probed further than that, but my guess is that now we check
>> for set-returning tlist items while the tlist still has grouping Vars,
>> thus missing the fact that there's a SRF represented by one of those
>> Vars.  This prompts us to flatten a subquery we shouldn't have
>> flattened (because that ends by introducing a SRF into the outer
>> WHERE).

> The first part of your diagnosis is correct.  This issue is caused by
> a failure to notice the SRF in the target list, as the item is hidden
> under a grouped Var.  This doesn't lead to incorrect subquery
> flattening though, since such a subquery must involve grouping, and
> is_simple_subquery() would refuse to flatten it.  Instead, it
> incorrectly indicates that the subquery's restriction clause is safe
> to push down, which mistakenly introduces SRFs into the subquery's
> WHERE quals.

Got it.

> (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?

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.

			regards, tom lane