Re: Early WIP/PoC for inlining CTEs
От | Tom Lane |
---|---|
Тема | Re: Early WIP/PoC for inlining CTEs |
Дата | |
Msg-id | 21958.1532476669@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Early WIP/PoC for inlining CTEs (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Early WIP/PoC for inlining CTEs
Re: Early WIP/PoC for inlining CTEs |
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2018-07-24 19:49:19 -0400, Tom Lane wrote: >> However, a singly-referenced SELECT CTE could reasonably be treated as >> equivalent to a sub-select-in-FROM, and then you would have the same >> mechanisms for preventing inlining as you do for those cases, >> e.g. OFFSET 0. And sticking in OFFSET 0 would be backwards-compatible >> too: your code would still work the same in older releases, unlike if >> we invent new syntax for this. > I still think this is just doubling down on prior mistakes. Not following what you think a better alternative is? I'd be the first to agree that OFFSET 0 is a hack, but people are used to it. Assuming that we go for inline-by-default for at least some cases, there's a separate discussion to be had about whether it's worth making a planner-control GUC to force the old behavior. I'm not very excited about that, but I bet some people will be. regards, tom lane
В списке pgsql-hackers по дате отправления: