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

  1. Fix inability to reference CYCLE column from inside its CTE.