ERROR: unsupported join alias expression

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: ERROR: unsupported join alias expression
Date: 2026-09-17 06:45:46
Message-ID: CAMbWs49q_gvoeOoF0+KZ-DpQaDb=nGFfSgrz2V_n1_64L4ZNVQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fuzzing with Claude on add_nullingrels_if_needed() found two cases
that fail with $subject.

create table t (a int);

-- 1
select count(j) from t x left join (t b cross join t c) j on true;
ERROR: unsupported join alias expression

-- 2
select (select j) from t x
left join ((select from t) b cross join (select from t) c) j on x.a = 1;
ERROR: unsupported join alias expression

The first one is raised in the parser. parseCheckAggregates()
flattens join alias Vars without a root, so it can't wrap the expanded
RowExpr in a PlaceHolderVar. I think we can leave such Vars
unexpanded when there is no root, because 1) the planner expands them
later as usual, and 2) a nulled whole-row Var can only match itself,
so nothing is lost for GROUP BY matching. See 0001.

The second one is raised in the planner. The join has no columns, so
the RowExpr has no Vars, and we fall back to evaluating the PHV at the
join's input rels. But that fallback is refused when the Var is an
outer reference from a subquery. I don't see why that's needed. Even
as an outer reference, the Var still refers to a join of root->parse,
since the planner always flattens with query == root->parse. So
looking the join up in root->parse gives the right relids for the PHV.
So I think we can just remove that check. See 0002.

- Richard

Attachment Content-Type Size
v1-0001-Fix-parser-failure-with-whole-row-join-alias-Vars.patch application/octet-stream 5.2 KB
v1-0002-Fix-planner-failure-with-zero-column-join-alias-V.patch application/octet-stream 3.9 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Rui Zhao 2026-09-17 06:51:04 Re: Persist slot invalidations before publishing them
Previous Message Alexander Korotkov 2026-09-17 06:38:34 Re: WAIT FOR NO_THROW option could use some documentation