Greetings, * Vik Fearing (vik.fear...@2ndquadrant.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
signature.asc
Description: PGP signature
