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 →
  1. Fix unsafe pushdown of quals referencing grouping Vars

  2. Introduce an RTE for the grouping step