Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?
| От | David G. Johnston |
|---|---|
| Тема | Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)? |
| Дата | |
| Msg-id | CAKFQuwYYEz7cwqLhevRLyaGSwNkARqJ9x+r+VyQ81Gite0pnHA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)? (David Rowley <david.rowley@2ndquadrant.com>) |
| Ответы |
Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?
Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)? |
| Список | pgsql-hackers |
On 28 January 2018 at 12:00, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
> On 01/27/2018 10:45 PM, Tom Lane wrote:
>> David Rowley <david.rowley@2ndquadrant.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.
В списке pgsql-hackers по дате отправления: