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

  1. Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL)

  2. Identity columns