Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: David Rowley <david.rowley@2ndquadrant.com>,
Tels <nospam-pg-abuse@bloodgate.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Stephen Froehlich <s.froehlich@cablelabs.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
Alvaro Herrera <alvherre@2ndquadrant.com>
Date: 2018-01-27T22:55:33Z
Lists: pgsql-hackers, pgsql-novice
Hi, On 01/27/2018 10:09 PM, David Rowley wrote: > On 27 January 2018 at 00:03, Tels <nospam-pg-abuse@bloodgate.com> wrote: >> Looking at the patch, at first I thought the order was sorted and you >> swapped STORAGE and STATISTICS by accident. But then, it seems the order >> is semi-random. Should that list be sorted or is it already sorted by some >> criteria that I don't see? >> >> - <literal>INCLUDING DEFAULTS INCLUDING IDENTITY INCLUDING >> CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING >> COMMENTS</literal>. >> + <literal>INCLUDING DEFAULTS INCLUDING IDENTITY INCLUDING >> CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING STATISTICS >> INCLUDING COMMENTS</literal>. > > It looks like they were in order of how they're defined in enum > TableLikeOption up until [1], then I'm not so sure what the new order > is based on after that. > > 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. > > On looking at this I realised I missed changing the syntax synopsis. > The attached adds this. > Thanks for working on a patch. This should have been in the statistics patch, no doubt about that. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL)
- 911e6236bab5 10.4 landed
- 5564c1181548 11.0 landed
-
Identity columns
- 321732705363 10.0 cited