Re: [HACKERS] REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Vik Fearing
Subject Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Date
Msg-id 57479e55-ce26-5c00-2525-09e267c7224a@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael@paquier.xyz>)
Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 16/01/2019 18:59, Alvaro Herrera wrote:
> On 2019-Jan-16, Michael Paquier wrote:
> 
>> Regarding the grammar, we tend for the last couple of years to avoid
>> complicating the main grammar and move on to parenthesized grammars
>> (see VACUUM, ANALYZE, EXPLAIN, etc).  So in the same vein I think that
>> it would make sense to only support CONCURRENTLY within parenthesis
>> and just plugin that with the VERBOSE option.
> 
> That's my opinion too, but I was outvoted in another subthread -- see
> https://postgr.es/m/20181214144529.wvmjwmy7wxgmgyb3@alvherre.pgsql
> Stephen Frost, Andrew Gierth and Andres Freund all voted to put
> CONCURRENTLY outside the parens.  It seems we now have three votes to
> put it *in* the parens (you, Peter Eisentraut, me).  I guess more votes
> are needed to settle this issue.

My vote is to have homogeneous syntax for all of this, and so put it in
parentheses, but we should also allow CREATE INDEX and DROP INDEX to use
parentheses for it, too.

I supposed we'll keep what would then be the legacy syntax for a few
decades or more.
-- 
Vik Fearing                                          +33 6 46 75 15 36
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: More OpenBSD portability fun: getopt() fails on --option
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] pgbench tap tests fail if the path contains a perlspecial character