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

From Andres Freund
Subject Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Date
Msg-id 20190123183321.ecxr5wg33e76ywkq@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2019-01-23 13:17:26 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2019 at 9:01 PM Vik Fearing <vik.fearing@2ndquadrant.com> wrote:
> > 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.
> 
> +1 for all three being the same.  I could see allowing only the
> unparenthesized format for all three, or allowing both forms for all
> three, but I think having only one form for each and having them not
> agree will be too confusing.

It seems quite unnecesarily confusing to me to require parens for
REINDEX CONCURRENTLY when we've historically not required that for
CREATE/DROP INDEX CONCURRENTLY. Besides that, training people that it's
the correct form to use parens for CIC/DIC, creates an unnecessary
version dependency.

I think it actually makes sense to see the CONCURRENTLY versions as
somewhat separate types of statements than the non concurrent
versions. They have significantly different transactional behaviour
(like not being able to be run within one, and leaving gunk behind in
case of error). For me it semantically makes sense to have that denoted
at the toplevel, it's a related but different type of DDL statement.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ArchiveEntry optional arguments refactoring
Next
From: Chapman Flack
Date:
Subject: Re: ArchiveEntry optional arguments refactoring