|
7 | 7 | * |
8 | 8 | * |
9 | 9 | * IDENTIFICATION |
10 | | - * $Header: /cvsroot/pgsql/src/backend/parser/parse_expr.c,v 1.45 1999/05/13 07:28:38 tgl Exp $ |
| 10 | + * $Header: /cvsroot/pgsql/src/backend/parser/parse_expr.c,v 1.46 1999/05/18 23:40:05 tgl Exp $ |
11 | 11 | * |
12 | 12 | *------------------------------------------------------------------------- |
13 | 13 | */ |
@@ -478,17 +478,23 @@ transformExpr(ParseState *pstate, Node *expr, int precedence) |
478 | 478 | * At least one construct (BETWEEN/AND) puts the same nodes |
479 | 479 | *into two branches of the parse tree; hence, some nodes |
480 | 480 | *are transformed twice. |
481 | | - * The three cases below come from transforming function calls. |
482 | | - * Let's try just passing them through... |
483 | | - * - thomas 1998-03-14 |
| 481 | + * Another way it can happen is that coercion of an operator or |
| 482 | + *function argument to the required type (via coerce_type()) |
| 483 | + *can apply transformExpr to an already-transformed subexpression. |
| 484 | + *An example here is "SELECT count(*) + 1.0 FROM table". |
| 485 | + * Thus, we can see node types in this routine that do not appear in the |
| 486 | + *original parse tree. Assume they are already transformed, and just |
| 487 | + *pass them through. |
| 488 | + * Do any other node types need to be accepted? For now we are taking |
| 489 | + *a conservative approach, and only accepting node types that are |
| 490 | + *demonstrably necessary to accept. |
484 | 491 | */ |
485 | 492 | caseT_Expr: |
486 | 493 | caseT_Var: |
487 | 494 | caseT_Const: |
488 | | -/* T_Param comes from implicit function calls in INSERT/VALUE statements. |
489 | | - * - thomas 1998-06-11 |
490 | | - */ |
491 | 495 | caseT_Param: |
| 496 | +caseT_Aggref: |
| 497 | +caseT_ArrayRef: |
492 | 498 | { |
493 | 499 | result= (Node*)expr; |
494 | 500 | break; |
|