Re: Fwd: pg18 bug? SELECT query doesn't work
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2026-01-08T04:03:02Z
Lists: pgsql-hackers, pgsql-general
Richard Guo <guofenglinux@gmail.com> writes: > The underlying expression of a join alias Var can only be a Var > (potentially coerced) from one of the join's input rels, or a COALESCE > expression containing the two input Vars. Therefore, it should not be > able to contain SRFs or volatile functions, and thus we do not need to > expand it beforehand. [ itch... ] That statement is false in general, because subquery pullup within the subquery can replace a sub-subquery's output Vars with expressions. It might be okay for this purpose, as I think we'd not pull up if the sub-subquery's output expressions are volatile or SRFs. These assumptions had better be well commented though. The larger point here is that this behavior is all recursive, and we can happily end with an expression that's been pulled up several levels; we'd better make sure the right checks happen. So I'm a little bit distressed that planner.c's invocations of flatten_group_exprs are not at all analogous to its usage of flatten_join_alias_vars. The latter pattern has a couple of decades of usage to lend credence to the assumption that it's correct. flatten_group_exprs, um, not so much. It may be fine, given the fact that grouping Vars can appear within much less of the query than join aliases. But in view of the present bug, I'm feeling nervous. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix unsafe pushdown of quals referencing grouping Vars
- 7650eabb662f 18.2 landed
- 34740b90bc12 19 (unreleased) landed
-
Introduce an RTE for the grouping step
- 247dea89f761 18.0 cited