Re: Consistent segfault in complex query
| От | Tom Lane |
|---|---|
| Тема | Re: Consistent segfault in complex query |
| Дата | |
| Msg-id | 6464.1536877776@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Consistent segfault in complex query (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
| Список | pgsql-hackers |
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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?
I don't really think the amount of complexity that would add is something
to consider for a back-patchable fix.
> 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.
Given that this bug has been there since the late bronze age and just now
got detected, I think that optimizing the fix for especially improbable
cases ought not be the first thing on our minds. Let's just get it to
work reliably.
regards, tom lane
В списке pgsql-hackers по дате отправления: