ctelevelsup is kind of a pain in the neck

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: ctelevelsup is kind of a pain in the neck
Date: 2008-10-06 13:36:17
Message-ID: 29082.1223300177@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I noticed this perfectly valid query doesn't work in CVS HEAD:

regression=# with q(x) as (select 1) select * from q where 1 in (select q.x);
ERROR: could not find CTE "q"

The failure occurs while markTargetListOrigin is trying to process the
"select q.x" sub-select's targetlist: it correctly finds the CTE for
"q" in the outer query (one ParseState level up), and then hands that
off to GetCTEForRTE, which sees that the RTE has ctelevelsup == 0 and
therefore expects to find the CTE in the current ParseState. Ooops.

What this means is that GetCTEForRTE needs an extra levelsup parameter
to add to the RTE's ctelevelsup setting; and there are probably quite a
few other places in need of similar adjustment. We've been through
similar hassles with varlevelsup and related fields, so it's surely
doable, but still a pain.

Before I go off and do that, I was just wondering if anyone had a
brilliant idea for a better way to represent cross-query-level
references. I thought for a little bit about storing absolute instead
of relative level numbers, but soon concluded that that cure would be
far worse than the disease. But maybe there's some other way that we
just haven't considered?

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-10-06 14:01:01 Shouldn't pg_settings.enumvals be array of text?
Previous Message Kellyton Campos Feitosa - GYN 2008-10-06 13:22:00 Monitoring postgres