Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

On Mon, Jan 29, 2018 at 2:55 AM, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
wrote:

> On 28 January 2018 at 12:00, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
> wrote:
> > On 01/27/2018 10:45 PM, Tom Lane wrote:
> >> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> >>> I'd offer to put it back to the order of the enum, but I want to
> >>> minimise the invasiveness of the patch. I'm not sure yet if it should
> >>> be classed as a bug fix or a new feature.
> >>
> >> FWIW, I'd call it a new feature.
> >>
> >
> > I'm not sure what exactly the feature would be? I mean "keep statistics
> > even if you only ask for indexes" does not seem particularly helpful to
> > me. So I see it more like a bug - I certainly think it should have been
> > handled differently in 10.
>
> Now I'll ask; On me doing so, would anyone have pushed back on that
> request and said that what I'm asking is a separate feature?
>
> If the answer to that is "no", then this is a bug that should be fixed
> and backpacked to v10.

​Its a bug of omission (I'm going with no one saying no to your
proposition) - though that still doesn't automatically allow us to
back-patch it.

This bug has an obvious if annoying work-around and fixing the bug will
likely cause people's code, that uses said work-around, to fail. Breaking
people's working code in stable release branches is generally a no-no.

However, given that this was discovered 4 months after the feature was
released suggests to me that we are justified, and community-serving, to
back-patch this. Put more bluntly, we can ask for more leeway in the first
few patch releases of a new feature since more people will benefit from 5
years of a fully-baked feature than may be harmed by said change. We
shouldn't abuse that but an obvious new feature bug/oversight like this
seems reasonable.

David J.