Re: Early WIP/PoC for inlining CTEs
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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-01-28T19:00:33Z
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
On Mon, Jan 21, 2019 at 10:28 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andreas Karlsson <andreas@proxel.se> writes: > > I have a minor biksheddish question about the syntax. > > You proposed: > > WITH cte_name [[NOT] MATERIALIZED] AS (query) main_query > > While Andrew proposed: > > WITH cte_name AS [[NOT] MATERIALIZED] (query) main_query > > Do people have any preference between these two? > > FWIW, I'd independently thought that the latter is more readable, > and probably less likely to have syntax problems with future > extensions (since AS is already fully reserved). Didn't get > around to mentioning it yet, but +1 for putting AS first. It seems to me that as long as the query has to be surrounded by non-optional parentheses and the options list never starts with a parenthesis, there isn't much room for a grammar conflict either way. If the query didn't have to be surrounded by parentheses, you would want to put the options before the word AS so that the word AS would serve as an unambiguous terminator for the options specification, but if the query must be preceded by an opening parenthesis then as long as the options list can't include an option that begins with such a parenthesis we are in good shape. However, generally we have not had great luck with just sticking keywords in there (cf. VACUUM, ANALYZE, EXPLAIN, COPY) which is why I suggested using a flexible syntax with parenthesized options. And then you're going to have trouble getting bison to figure out what to do after... WITH something AS ( some_keyword ...because some_keyword might be the an option name or the first word of a query. And putting that syntax before AS isn't any better, because now it can be confused with a column name list. I am not deeply worked up about this, just proposing some things to think about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company