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 pathTABLE 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:699Yeah. 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