ctelevelsup is kind of a pain in the neck
От | Tom Lane |
---|---|
Тема | ctelevelsup is kind of a pain in the neck |
Дата | |
Msg-id | 29082.1223300177@sss.pgh.pa.us обсуждение исходный текст |
Список | 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
В списке pgsql-hackers по дате отправления: