Re: [HACKERS] WITH clause in CREATE STATISTICS - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [HACKERS] WITH clause in CREATE STATISTICS
Date
Msg-id CANP8+jJqV+gwEJs0_X09S_G7VDZseAt-9WAjQq6=tsdu6WJk-A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] WITH clause in CREATE STATISTICS  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: [HACKERS] WITH clause in CREATE STATISTICS  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 3 May 2017 at 23:31, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:

>> It also seems like we don't need to have *both* fully-reserved keywords
>> introducing each clause *and* parentheses around the lists.  Maybe
>> dropping the parens around the stats-types list and the column-names
>> list would help to declutter?  (But I'd keep parens around the WITH
>> options, for consistency with other statements.)

+1

>> One other point is that as long as we've got reserved keywords introducing
>> each clause, there isn't actually an implementation reason why we couldn't
>> accept the clauses in any order.  Not sure I want to document it that way,
>> but it might not be a bad thing if the grammar was forgiving about whether
>> you write the USING or ON part first ...
>
> +1 for allowing arbitrary order of clauses.

+1

> I would document it with the
> USING clause at the end, and have that be what psql supports and pg_dump
> produces. Since there are no WITH options now we should leave that out
> until it's required.

Let's record the target syntax in parser comments so we can just slot
things in when needed later, without rediscussion.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] PROVE_FLAGS
Next
From: Jeff Davis
Date:
Subject: Re: [HACKERS] [POC] hash partitioning