Re: Early WIP/PoC for inlining CTEs
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Vik Fearing <vik.fearing@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>,
Andreas Karlsson <andreas@proxel.se>,
Andres Freund <andres@anarazel.de>,
Thomas Munro <thomas.munro@enterprisedb.com>,
Andrew Gierth <andrew@tao11.riddles.org.uk>,
David Fetter <david@fetter.org>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-03T15:39:57Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Prevent inlining of multiply-referenced CTEs with outer recursive refs.
- 9476131278c7 12.0 landed
-
Allow user control of CTE materialization, and change the default behavior.
- 608b167f9f9c 12.0 landed
-
Split QTW_EXAMINE_RTES flag into QTW_EXAMINE_RTES_BEFORE/_AFTER.
- 18c0da88a5d9 12.0 landed
-
document when PREPARE uses generic plans
- fab9d1da4a21 9.6.0 cited
Vik Fearing <vik.fearing@2ndquadrant.com> writes: > On 28/01/2019 23:05, Tom Lane wrote: >> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >>> Or put it at the end? >>> WITH ctename AS ( query ) MATERIALIZED >> 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. > On the other hand, the end is where the other options go (that we > haven't implemented yet). See <search or cycle clause>. Yeah, I noticed that too while working on the latest patch revision. ISTM that's actually an argument for *not* putting PG-specific syntax there. We'd increase the risk of conflicting with future spec additions, assuming that they continue to add stuff at the end rather than just after AS. regards, tom lane