| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Subject: | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |
| Date: | 2018-12-14 14:45:29 |
| Message-ID: | 20181214144529.wvmjwmy7wxgmgyb3@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018-Dec-14, Stephen Frost wrote:
> That wasn't what was asked and I don't think I see a problem with having
> concurrently be allowed in the parentheses. For comparison, it's not
> like "explain analyze select ..." or "explain buffers select" is
> terribly good grammatical form.
... and we don't allow EXPLAIN BUFFERS at all, and if we had had a
parenthesized option list in EXPLAIN when we invented EXPLAIN ANALYZE, I
bet we would have *not* made the ANALYZE keyword appear unadorned in
that command.
> If you wanted to try to get to a better form for the spelled out
> sentence, I would think:
>
> concurrently reindex table test
>
> would probably be the approach to use,
I think this is terrible from a command-completion perspective, and from
a documentation perspective (Certainly we wouldn't have a manpage about
the "concurrently" command, for starters).
My vote goes to put the keyword inside of and exclusively in the
parenthesized option list.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2018-12-14 14:52:22 | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |
| Previous Message | Jonah H. Harris | 2018-12-14 14:39:16 | Re: Row Visibility and Table Access Methods |