Re: Early WIP/PoC for inlining CTEs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Early WIP/PoC for inlining CTEs
Дата
Msg-id 17787.1548791564@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Early WIP/PoC for inlining CTEs  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Early WIP/PoC for inlining CTEs  (Merlin Moncure <mmoncure@gmail.com>)
Re: Early WIP/PoC for inlining CTEs  (David Fetter <david@fetter.org>)
Re: Early WIP/PoC for inlining CTEs  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Jan 28, 2019 at 05:05:32PM -0500, Tom Lane wrote:
>> Yeah, I thought about that too, but it doesn't seem like an improvement.
>> If the query is very long (which isn't unlikely) I think people would
>> prefer to see the option(s) up front.

> Having these options at the front of the WITH clause looks more
> natural to me.

Well, we've managed to get agreement on the semantics of this thing,
let's not get hung up on the syntax details.

I propose that we implement and document this as

    WITH ctename AS [ MATERIALIZE { ON | OFF } ] ( query )

which is maybe a bit clunky but not awful, and it would leave room
to generalize it to "AS [ optionname optionvalue [ , ... ] ]" if we
ever need to.  Looking at the precedent of e.g. EXPLAIN, we could
probably allow just "MATERIALIZE" as well, with the boolean value
defaulting to true.

            regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Следующее
От: Jesper Pedersen
Дата:
Сообщение: Re: pg_upgrade: Pass -j down to vacuumdb