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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] tables >2GB
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Alpha initdb fixed!