Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible |
Дата | |
Msg-id | 3511E233.1E822290@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
> > Thomas, I believe this is the problem with my processing a node > > twice. Do you have a fix for that, or should I make one? > So, the patch for "function() BETWEEN" helps, but I'm still not sure > it is safe, since I don't know how these nodes might be handled deeper > in the backend. Bruce, did I remember to actually enclose the patch for you? Looks to me like I didn't, so here it is again... - Tom *** ../src/backend/parser/parse_expr.c.orig Sun Mar 1 15:04:42 1998 --- ../src/backend/parser/parse_expr.c Sun Mar 15 05:49:03 1998 *************** *** 301,306 **** --- 301,321 ---- result = (Node *) expr; break; } + /* These nodes do _not_ come from the original parse tree. + * They result from parser transformation in this phase. + * At least one construct (BETWEEN/AND) puts the same nodes + * into two branches of the parse tree. Hence, some nodes + * are transformed twice. These nodes come from transforming + * a function call. Let's try just passing them through... + * - thomas 1998-03-14 + */ + case T_Expr: + case T_Var: + case T_Const: + { + result = (Node *) expr; + break; + } default: /* should not reach here */ elog(ERROR, "transformExpr: does not know how to transform node %d",
В списке pgsql-hackers по дате отправления: