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

From Vik Fearing
Subject Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Date
Msg-id a03a615c-3224-e54f-76ee-fddd6f524cbb@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Sergei Kornilov <sk@zsrv.org>)
Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael@paquier.xyz>)
Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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 never said anything about WITH.
--
Vik Fearing                                          +33 6 46 75 15 36
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: current_logfiles not following group access and instead followslog_file_mode permissions
Next
From: Alvaro Herrera
Date:
Subject: Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)