From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Jeremy Finzel <finzelj@gmail.com>,
        Andrew Gierth <andrew@tao11.riddles.org.uk>,
        pgsql-hackers@postgresql.org
Subject: Re: Early WIP/PoC for inlining CTEs
In-reply-to: <20180724235416.c7c4az6kjxyszkgt@alap3.anarazel.de>
References: <87sh48ffhb.fsf@news-spur.riddles.org.uk>
 <CAMa1XUiQqZmUDYnQCdHejsy35qXC3-YQeVmbBi9qdOW7QYY_nA@mail.gmail.com>
 <20180724231010.quiaae5qyfrreiyj@alap3.anarazel.de>
 <21487.1532476159@sss.pgh.pa.us>
 <20180724235416.c7c4az6kjxyszkgt@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 24 Jul 2018 16:54:16 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21957.1532476669.1@sss.pgh.pa.us>
Date: Tue, 24 Jul 2018 19:57:49 -0400
Message-ID: <21958.1532476669@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2018-07-24 19:49:19 -0400, Tom Lane wrote:
>> However, a singly-referenced SELECT CTE could reasonably be treated as
>> equivalent to a sub-select-in-FROM, and then you would have the same
>> mechanisms for preventing inlining as you do for those cases,
>> e.g. OFFSET 0.  And sticking in OFFSET 0 would be backwards-compatible
>> too: your code would still work the same in older releases, unlike if
>> we invent new syntax for this.

> I still think this is just doubling down on prior mistakes.

Not following what you think a better alternative is?  I'd be the
first to agree that OFFSET 0 is a hack, but people are used to it.

Assuming that we go for inline-by-default for at least some cases,
there's a separate discussion to be had about whether it's worth
making a planner-control GUC to force the old behavior.  I'm not
very excited about that, but I bet some people will be.

			regards, tom lane