Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: 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>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>
Date: 2018-01-27T21:09:15Z
Lists: pgsql-hackers, pgsql-novice
Attachments
- create_table_like_statistics_v2.patch (application/octet-stream) patch v2
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. [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3217327053638085d24dd4d276e7c1f7ac2c4c6b -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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