Re: Tricky bugs in concurrent index build

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Tricky bugs in concurrent index build
Дата
Msg-id 200608251455.k7PEtn303115@momjian.us
обсуждение исходный текст
Ответ на Re: Tricky bugs in concurrent index build  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Tricky bugs in concurrent index build
Re: Tricky bugs in concurrent index build
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Safer auto-initdb for RPM init script
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Tricky bugs in concurrent index build