Re: [HACKERS] CTE inlining - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [HACKERS] CTE inlining
Date
Msg-id 9110f786-a412-0b07-b59c-1844c3368a4f@2ndQuadrant.com
Whole thread Raw
In response to Re: [HACKERS] CTE inlining  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 05/09/2017 04:14 PM, Tom Lane wrote:
>
> Well, TBH that is pre-judging what (if anything) is going to be changed
> by a feature that we don't even have design consensus on, let alone a
> patch for.  I don't think that's an improvement or a good service to
> our users; it's just promoting confusion.  I think that until we do have
> a design and a patch, we're better off leaving the docs reading the way
> they have for the past eight years.
>
> I'm also a bit mystified by the apparent urgency to change something,
> anything, in this area when we're already past feature freeze.  This
> would be a fit subject for discussion several months from now when
> v11 development opens, but right now it's just distracting us from
> stabilizing v10.
>
>             


+1. We should not be in the business of documenting or declaring our
intention of having vaporware. Say we get a patch and for some reason it
gets rejected. We've had features that took two or three releases to get
accepted. This is why we've historically shied away from roadmaps. And
we've been bitten in the past by deprecating things only to undeprecate
them later.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)
Next
From: Chapman Flack
Date:
Subject: Re: [HACKERS] idea: custom log_line_prefix components besidesapplication_name