Re: Early WIP/PoC for inlining CTEs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Early WIP/PoC for inlining CTEs
Date
Msg-id 17787.1548791564@sss.pgh.pa.us
Whole thread Raw
In response to Re: Early WIP/PoC for inlining CTEs  (Michael Paquier <michael@paquier.xyz>)
Responses 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>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Next
From: Jesper Pedersen
Date:
Subject: Re: pg_upgrade: Pass -j down to vacuumdb