Re: Tricky bugs in concurrent index build - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Tricky bugs in concurrent index build
Date
Msg-id 200608251455.k7PEtn303115@momjian.us
Whole thread Raw
In response to Re: Tricky bugs in concurrent index build  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Tricky bugs in concurrent index build
Re: Tricky bugs in concurrent index build
List pgsql-hackers
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > I see we have:
> >  CREATE index_opt_unique INDEX CONCURRENTLY index_name ...
> > which explains how this error occurs.
> 
> Maybe to you, but I'm still caffeine-deprived and don't exactly see what
> it was that Greg mistyped.  AFAICS he'd have to type CONCURRENTLY twice
> to get into a scenario where the proposed warning would fire.
> 
> > But might it not be better to have this instead?
> >   CREATE CONCURRENTLY index_opt_unique INDEX index_name ...
> 
> When I was fooling with gram.y I was thinking that actually
> 
>     CREATE [UNIQUE] INDEX indexname [CONCURRENTLY] ...
> 
> would be the most grammatical thing.  But I can live with putting

The original thinking was to use CONCURRENT, and CREATE CONCURRENT INDEX
sounded like a different type of index, not a different way to build the
index.  I don't think CONCURRENTLY has that problem, so CREATE
CONCURRENTLY INDEX sounds good.  To read in English, it would be read as
CREATE CONCURRENTLY, INDEX ii.

> it right after CREATE, too.  Or there was the proposal to put it
> first:
> 
>     [CONCURRENTLY] CREATE [UNIQUE] INDEX indexname ...

I think this suggested the command was CONCURRENTLY, which isn't good.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Safer auto-initdb for RPM init script
Next
From: Tom Lane
Date:
Subject: Re: Tricky bugs in concurrent index build