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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
