Re: Early WIP/PoC for inlining CTEs
От | Thomas Munro |
---|---|
Тема | Re: Early WIP/PoC for inlining CTEs |
Дата | |
Msg-id | CAEepm=2n8hChj548H0R5g5JAx3cokpZwTqRzYhN2oVGqBONwOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Early WIP/PoC for inlining CTEs (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Early WIP/PoC for inlining CTEs
|
Список | pgsql-hackers |
On Sat, Jan 12, 2019 at 7:19 AM Andres Freund <andres@anarazel.de> wrote: > On 2019-01-11 11:12:25 -0500, Robert Haas wrote: > > I actually think that we should go "all in" here and allow the user to > > specify either that they want materialization or that they don't want > > materialization. If they specify neither, then we make some decision > > which we may change in a future release. If they do specify > > something, we do that. > > +many I think the syntax as proposed is almost OK if we only want to grandfather in our historically hintful CTEs but discourage the development of any future kinds of hints. Even then I don't love the way it formalises a semi-procedural step at the same language level as a glorious declarative relational query. Maybe we could consider a more extensible syntax that is attached to the contained SELECT rather than the containing WITH. Then CTEs would be less special; there'd be a place to put hints controlling top-level queries, subselects, views etc too (perhaps eventually join hints, parallelism hints etc, but "materialize this" would be just another one of those things). That'd be all-in. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: