Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?
От | Tomas Vondra |
---|---|
Тема | Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)? |
Дата | |
Msg-id | ea0a3562-fba8-a52d-a31a-71e05bb50837@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)? (David Rowley <david.rowley@2ndquadrant.com>) |
Список | pgsql-hackers |
On 02/01/2018 07:26 AM, David Rowley wrote: > On 30 January 2018 at 14:14, David G. Johnston > <david.g.johnston@gmail.com> wrote: >> 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. > > That seems quite rational. > > To prevent this getting lost I've added it to the March commitfest [1]. > > In the commitfest application I've classed it (for now) as a bug fix. > If that changes then we can alter it in the commitfest app. > > [1] https://commitfest.postgresql.org/17/1501/ > Thank you for taking care of this. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: