Re: Backport "WITH ... AS MATERIALIZED" syntax to <12?
От | Colin Watson |
---|---|
Тема | Re: Backport "WITH ... AS MATERIALIZED" syntax to <12? |
Дата | |
Msg-id | 20191019092238.GN16234@riva.ucam.org обсуждение исходный текст |
Ответ на | Re: Backport "WITH ... AS MATERIALIZED" syntax to <12? (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: Backport "WITH ... AS MATERIALIZED" syntax to <12?
Re: Backport "WITH ... AS MATERIALIZED" syntax to <12? |
Список | pgsql-hackers |
On Sat, Oct 19, 2019 at 05:01:04AM +0100, Andrew Gierth wrote: > >>>>> "Michael" == Michael Paquier <michael@paquier.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@canonical.com]
В списке pgsql-hackers по дате отправления: