On Sat, Jan 19, 2019 at 03:01:07AM +0100, Vik Fearing wrote:
> On 19/01/2019 02:33, Michael Paquier wrote:
>> On Fri, Jan 18, 2019 at 07:58:06PM +0100, Vik Fearing wrote:
>>> 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.
>>
>> That would be a new thing as these variants don't exist yet, and WITH
>> is for storage parameters. In my opinion, the long-term take on doing
>> such things is that we are then able to reduce the number of reserved
>> keywords in the grammar. Even if for the case of CONCURRENTLY we may
>> see humans on Mars before this actually happens, this does not mean
>> that we should not do it moving forward for other keywords in the
>> grammar.
>
> I'm not sure I understand your point.
>
> I don't want a situation like this:
> CREATE INDEX CONCURRENTLY ...
> DROP INDEX CONCURRENTLY ...
> REINDEX INDEX (CONCURRENTLY) ...
>
> All three should be the same, and my suggestion is to add the
> parenthesized version to CREATE and DROP and not add the unparenthesized
> version to REINDEX.
I am not sure what is the actual reason which could force to decide
that all three queries should have the same grammar, and why this has
anything to do on a thread about REINDEX. REINDEX can work on many
more object types than an index so its scope is much larger, contrary
to CREATE/DROP INDEX. An advantage of using parenthesized grammar and
prioritize it is that you don't have to add it to the list of reserved
keywords, and the parser can rely on IDENT for its work.
I personally prefer the parenthesized grammar for that reason. If the
crowd votes in majority for the other option, that's of course fine to
me too.
> I never said anything about WITH.
Perhaps I have not explained my thoughts clearly here. My point was
that if some day we decide to drop the non-parenthesized grammar of
CREATE/DROP INDEX, one possibility would be to have a "concurrent"
option as part of WITH, even if that's used only now for storage
parameters. That's the only actual part of the grammar which is
extensible.
--
Michael