Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Greetings,

* Vik Fearing (vik(dot)fearing(at)2ndquadrant(dot)com) wrote:
> 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.

I'm still of the opinion that we should have CONCURRENTLY allowed
without the parentheses. I could see allowing it with them, as well,
but I do feel that we should be using the parentheses-based approach
more as a last-resort kind of thing instead of just baking in everything
to require them.

We have said before that we don't want to have things implemented in a
purely functional way (see the discussions around pglogical and such)
and while this isn't quite the same, I do think it heads in that
direction. It's certainly harder to have to think about how to
structure these commands so that they look like they belong in SQL but I
think it has benefits too.

Thanks!

Stephen