Re: Backport "WITH ... AS MATERIALIZED" syntax to <12?

+1 for the configuration option. Otherwise, migration is a nightmare -- so
many CTEs were written specifically to use the "optimization fence"
behavior. The lack of such configuration options is now a "migration fence".

On Sat, Oct 19, 2019 at 2:49 AM Colin Watson <cjwatson(at)canonical(dot)com> wrote:

> On Sat, Oct 19, 2019 at 05:01:04AM +0100, Andrew Gierth wrote:
> > >>>>> "Michael" == Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > > On Fri, Oct 18, 2019 at 02:21:30PM +0100, Colin Watson wrote:
> > >> However, an alternative would be to backport the new syntax to some
> > >> earlier versions. "WITH ... AS MATERIALIZED" can easily just be
> > >> synonymous with "WITH ... AS" in versions prior to 12; there's no
> > >> need to support "NOT MATERIALIZED" since that's explicitly
> > >> requesting the new query-folding feature that only exists in 12.
> > >> Would something like the attached patch against REL_11_STABLE be
> > >> acceptable? I'd like to backpatch it at least as far as PostgreSQL
> > >> 10.
> >
> > Michael> I am afraid that new features don't gain a backpatch. This is
> > Michael> a project policy. Back-branches should just include bug fixes.
> >
> > I do think an argument can be made for making an exception in this
> > particular case. This wouldn't be backpatching a feature, just accepting
> > and ignoring some of the new syntax to make upgrading easier.
>
> Right, this is my position too. I'm explicitly not asking for
> backpatching of the CTE-inlining feature, just trying to cope with the
> fact that we now have to spell some particular queries differently to
> retain the performance characteristics we need for them.
>
> I suppose an alternative would be to add a configuration option to 12
> that allows disabling inlining of CTEs cluster-wide: we could then
> upgrade to 12 with inlining disabled, add MATERIALIZED to the relevant
> queries, and then re-enable inlining. But I like that less because it
> would end up leaving cruft around in PostgreSQL's configuration code
> somewhat indefinitely for the sake of an edge case in upgrading to a
> particular version.
>
> --
> Colin Watson [cjwatson(at)canonical(dot)com]
>
>
>