Thread: BUG #17723: cache lookup failed for type 0
The following bug has been logged on the website: Bug reference: 17723 Logged by: Vik Fearing Email address: vik@postgresfriends.org PostgreSQL version: Unsupported/Unknown Operating system: Ubuntu Description: 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 Even though I did not need to add that WHERE clause because the CYCLE clause does it for me, I still should have been able to. And in any case, I should not have received an XX000 error.
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
On 12/16/22 18:10, Tom Lane wrote: > 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. Indeed, it should only depend on the TO and DEFAULT subclauses (not shown here). Thanks for the fix! -- Vik Fearing