Re: BUG #17723: cache lookup failed for type 0
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: vik@postgresfriends.org
Cc: pgsql-bugs@lists.postgresql.org,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2022-12-16T17:10:56Z
Lists: pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes: > This query: > WITH RECURSIVE > run(x, y) AS ( > SELECT 0, 0 > UNION ALL > SELECT x, y FROM run AS r WHERE r.is_cycle > ) > CYCLE x, y SET is_cycle USING path > TABLE run > ; > in which I mistakenly tried to access the is_cycle column from inside the > wle, provokes the following error: > ERROR: XX000: cache lookup failed for type 0 > LOCATION: typeOrDomainTypeRelid, parse_type.c:699 Yeah. We are calling addRangeTableEntryForCTE inside parse analysis of the CTE's query, and it's generating a ParseNamespaceItem with p_vartype = 0 because analyzeCTE hasn't yet identified the cycle_mark_type. That eventually results in a Var with vartype 0, confusing later parse analysis. It looks to me like we can just move that part of the code up to before we recurse to parse_sub_analyze, though. AFAICS, identification of the cycle column type needn't (and had better not) depend on any characteristics of the CTE's query. regards, tom lane
Commits
-
Fix inability to reference CYCLE column from inside its CTE.
- ea5ae4cae6a2 14.7 landed
- ae98debf77d4 15.2 landed
- 935277b24172 16.0 landed