> When we add a "temporary" GUC, we're taking on a gigantic burden. > Either we support it forever somehow, or we put it on a deprecation > schedule immediately and expect to be answering questions about it for > years after it's been removed. > > -1 for the GUC.
Absolutely.
So ISTM we have three choices:
1) we switch unmarked CTEs as inlineable by default in pg11. What seems likely to happen for a user that upgrades to pg11 is that 5 out of 10 CTE-using queries are going to become faster than with pg10, and they are going to be happy; 4 out of five are going to see no difference, but they didn't have to do anything about it; and the remaining query is going to become slower, either indistinguishably so (in which case they don't care and they remain happy because of the other improvements) or notably so, in which case they can easily figure where to add the MATERIALIZED option and regain the original performance.
2) unmarked CTEs continue to be an optimization barrier, but we add "WITH INLINED" so that they're inlineable. Some users may wonder about it and waste a lot of time trying to figure out which CTEs to add it to. They see a benefit in half the queries, which makes them happy, but they are angry that they had to waste all that time on the other queries.
3) We don't do anything, because we all agree that GUCs are not suitable. No progress. No anger, but nobody is happy either.
yes, these variants are all.
@2 is only little bit better than bad @3 - is not nice to have default behave different than any other and than what 90% developers expects.
