Re: Tricky bugs in concurrent index build
От | Gregory Stark |
---|---|
Тема | Re: Tricky bugs in concurrent index build |
Дата | |
Msg-id | 87k64xufkc.fsf@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Tricky bugs in concurrent index build (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Tricky bugs in concurrent index build
|
Список | pgsql-hackers |
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; -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: