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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Add default_val to pg_settings
Следующее
От: "Kellyton Campos Feitosa - GYN"
Дата:
Сообщение: Monitoring postgres