get_expr_result_type probably needs to be able to handle OpExpr as well

as FuncExpr, to cover cases where a function returning tuple is invoked
via an operator.
This commit is contained in:
Tom Lane 2005-04-25 20:59:44 +00:00
parent 238fb0342e
commit ea19c8772e
1 changed files with 8 additions and 2 deletions

View File

@ -7,7 +7,7 @@
* Copyright (c) 2002-2005, PostgreSQL Global Development Group * Copyright (c) 2002-2005, PostgreSQL Global Development Group
* *
* IDENTIFICATION * IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/utils/fmgr/funcapi.c,v 1.20 2005/04/05 06:22:14 tgl Exp $ * $PostgreSQL: pgsql/src/backend/utils/fmgr/funcapi.c,v 1.21 2005/04/25 20:59:44 tgl Exp $
* *
*------------------------------------------------------------------------- *-------------------------------------------------------------------------
*/ */
@ -229,6 +229,12 @@ get_expr_result_type(Node *expr,
NULL, NULL,
resultTypeId, resultTypeId,
resultTupleDesc); resultTupleDesc);
else if (expr && IsA(expr, OpExpr))
result = internal_get_result_type(get_opcode(((OpExpr *) expr)->opno),
expr,
NULL,
resultTypeId,
resultTupleDesc);
else else
{ {
/* handle as a generic expression; no chance to resolve RECORD */ /* handle as a generic expression; no chance to resolve RECORD */
@ -247,7 +253,7 @@ get_expr_result_type(Node *expr,
} }
/* /*
* get_expr_result_type * get_func_result_type
* As above, but work from a function's OID only * As above, but work from a function's OID only
* *
* This will not be able to resolve pure-RECORD results nor polymorphism. * This will not be able to resolve pure-RECORD results nor polymorphism.