public inbox for [email protected]  
help / color / mirror / Atom feed
From: 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: Tue, 06 Jan 2026 21:37:54 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAMbWs49jgcUS1yowhmDrsY-yDurniYSQWL_RpD8gPjKsah4fpw@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAMbWs49jxSN3AQ0xc9=Cyx8OgLbzu9su6QK68zKgZCsQxTk68w@mail.gmail.com>
	<CAMbWs49jgcUS1yowhmDrsY-yDurniYSQWL_RpD8gPjKsah4fpw@mail.gmail.com>

Richard Guo <[email protected]> writes:
> On Wed, Jan 7, 2026 at 3:52 AM Tom Lane <[email protected]> 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






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