Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Поиск
Список
Период
Сортировка
От Vik Fearing
Тема Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Дата
Msg-id a03a615c-3224-e54f-76ee-fddd6f524cbb@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael@paquier.xyz>)
Ответы 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>)
Список 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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: current_logfiles not following group access and instead followslog_file_mode permissions
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)