Re: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-02-22 15:33:08 -0500, Regina Obe wrote:
>> The CTE change in PostgreSQL 12 broke several of PostGIS regression tests
>> because many of our tests are negative tests that test to confirm we get
>> warnings in certain cases. In the past, these would output 1 notice because
>> the CTE was materialized, now they output 1 for each column.
>> An example is as follows:
>> WITH data AS ( SELECT '#2911' l, ST_Metadata(ST_Rescale( ST_AddBand(
>> ST_MakeEmptyRaster(10, 10, 0, 0, 1, -1, 0, 0, 0), 1, '8BUI', 0, 0 ),
>> 2.0, -2.0 )) m ) SELECT l, (m).* FROM data;

> I think there's a fair argument that we shouldn't inline in a way that
> increases the number of function calls due to (foo).*. In fact, I'm
> mildly surprised that we do that?

Well, is (foo).* all that much different from multiple written-out calls
to the function? But yeah, I'd rather try to address this complaint by
tweaking the inlining rules. It would certainly help if the function
had a realistic (high) cost estimate, because if it pretends to be cheap,
we really *should* be willing to inline it, one would think.

>> That said IS THERE or can there be a GUC like
>> set cte_materialized = on;
>> to get the old behavior?

> -incredibly many. That'll just make it harder to understand what SQL
> means.

Agreed. Now that we bit that bullet, I don't want to make things even
messier with a GUC.

The thing to do if you want to force backwards-compatible behavior without
using new-in-v12 syntax is to insert good ol' OFFSET 0 in the CTE query.

regards, tom lane