Re: Consistent segfault in complex query

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Consistent segfault in complex query
Дата
Msg-id 87sh2dm4zs.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Consistent segfault in complex query  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Consistent segfault in complex query  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 >> What I'm wondering is whether the param in the copied estate
 >> shouldn't rather be just a proxy for the one in the original estate
 >> - if we need to evaluate it, then do so in the original estate,
 >> store the value there, and copy the value back into the EPQ
 >> plantree.

 Tom> Don't think that's going to work; the EPQ environment doesn't have
 Tom> any way to know that an execPlan link is pointing to something in
 Tom> a different estate.

But can't such a way be created? e.g. by pointing execPlan to a special
proxy node that points back to the original estate?

 Tom> Your other idea of forcing initPlan parameters to be evaluated
 Tom> before we enter the EPQ execution environment is probably more
 Tom> workable. It would be annoying to do that for every initPlan in
 Tom> sight, but I think we could look at the subplan's extParam to see
 Tom> whether it potentially references that parameter. (Although
 Tom> really, in most scenarios it wouldn't matter because all the
 Tom> initPlans in a data-modifying query are probably referenced in the
 Tom> subplan anyhow ...)

Well, the case of UPDATE ... SET foo = case when x then (select thing
from big_cte) else (select thing from other_big_cte) end will be rather
annoying if we end up forcing both initplans to execute.

-- 
Andrew (irc:RhodiumToad)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Consistent segfault in complex query
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Consistent segfault in complex query