Re: Tricky bugs in concurrent index build

Gregory Stark wrote:
> Do we want something like this? I just made this error myself so unless I'm
> special (pauses for jokes) I imagine others would be prone to it as well.
>
> I would normally be pretty leery of code like this but it seems unlikely
> anyone would actually want an index named "concurrently" and the consequences
> if you get it wrong in a production environment are pretty dire. We might even
> consider making it an outright error.
>
>
> --- gram.y 25 Aug 2006 10:14:17 +0100 2.558
> +++ gram.y 25 Aug 2006 14:04:54 +0100
> @@ -56,6 +56,7 @@
> #include "commands/defrem.h"
> #include "nodes/makefuncs.h"
> #include "parser/gramparse.h"
> +#include "parser/scansup.h"
> #include "storage/lmgr.h"
> #include "utils/date.h"
> #include "utils/datetime.h"
> @@ -3653,6 +3654,12 @@
> opt_definition OptTableSpace where_clause
> {
> IndexStmt *n = makeNode(IndexStmt);
> +
> + if (!strcmp(downcase_truncate_identifier($4,20,false), "concurrently"))
> + ereport(WARNING,
> + (errcode(ERRCODE_SYNTAX_ERROR),
> + errmsg("performing non-concurrent index build of index named \"concurrently\"")));
> +
> n->unique = $2;
> n->concurrent = false;
> n->idxname = $4;
>

I see we have:

CREATE index_opt_unique INDEX CONCURRENTLY index_name ...

which explains how this error occurs. But might it not be better to have
this instead?

CREATE CONCURRENTLY index_opt_unique INDEX index_name ...

Then ISTM no ambiguity could arise (and it's also closer to grammatical
English, if that matters).

Just a thought

cheers

andrew