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