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