Re: [BUG] Remove self joins causes 'variable not found in subplan target lists' error
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Sergey Soloviev <sergey.soloviev@tantorlabs.ru>,
pgsql-hackers@lists.postgresql.org
Date: 2025-08-25T16:25:10Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix semijoin unique-ification for child relations
- 58ea074f1433 18.0 landed
- 97b0f36bde9a 19 (unreleased) landed
-
Fix "variable not found in subplan target lists" in semijoin de-duplication.
- b8a1bdc458e3 19 (unreleased) landed
- 3aee6283709f 18.0 landed
-
Recalculate where-needed data accurately after a join removal.
- a3179ab692be 18.0 cited
Richard Guo <guofenglinux@gmail.com> writes: > The proposed patch can fix this error. However, I'm wondering if we > could address it from the unique-ification side instead. If a Var > we're trying to unique-ify is known to be equal to a constant, then we > shouldn't need to unique-ify that Var Yeah. I think this is an oversight in create_unique_paths(): it's building an ORDER BY list without consideration for the possibility that some of the entries are known to be constant. In fact, because make_pathkeys_for_sortclauses will get rid of redundancies, this example actually ends up with a unique_rel whose unique_pathkeys are shorter than the unique_groupclause, which is pretty bogus. Not sure about a good way to make it account for that though. Detection of redundancies of this sort is kind of buried in pathkey construction, but in this context we'd like to find out earlier: we need to avoid attaching a new tlist entry if the expression is constant, else we'll still get the failure. regards, tom lane