Re: BUG #17723: cache lookup failed for type 0
От | Tom Lane |
---|---|
Тема | Re: BUG #17723: cache lookup failed for type 0 |
Дата | |
Msg-id | 3697954.1671210656@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #17723: cache lookup failed for type 0 (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #17723: cache lookup failed for type 0
|
Список | 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
В списке pgsql-bugs по дате отправления: