Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible |
Дата | |
Msg-id | 350DF735.8B39A15A@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible
|
Список | pgsql-hackers |
> > 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. > > Ship the patch over here and I will have a look at it. OK, here it is... - 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 по дате отправления: