From ae9a07bf9e34f48ddfc05e187b9a5dde963b3dee Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 3 Jul 2005 21:14:18 +0000 Subject: [PATCH] Don't try to constant-fold functions returning RECORD. We were never able to do this before, but I had tried to make an exception for functions with OUT parameters. Michael Fuhr found one problem with it already, and I found another, which was it didn't work for strict functions with a NULL input. While both of these could be worked around, the probability that there are more gotchas seems high; I think prudence dictates just reverting to the former behavior for now. Accordingly, remove the kluge added to get_expr_result_type() for Michael's case. --- src/backend/optimizer/util/clauses.c | 18 ++++++++++------ src/backend/utils/fmgr/funcapi.c | 32 +--------------------------- 2 files changed, 12 insertions(+), 38 deletions(-) diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c index 38291be27a..496a4b03f4 100644 --- a/src/backend/optimizer/util/clauses.c +++ b/src/backend/optimizer/util/clauses.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/util/clauses.c,v 1.199 2005/06/26 22:05:38 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/util/clauses.c,v 1.200 2005/07/03 21:14:17 tgl Exp $ * * HISTORY * AUTHOR DATE MAJOR EVENT @@ -2200,13 +2200,17 @@ evaluate_function(Oid funcid, Oid result_type, List *args, return NULL; /* - * Can't simplify if it returns RECORD, except in the case where it has - * OUT parameters, since it will be needing an expected tupdesc which we - * can't supply here. + * Can't simplify if it returns RECORD. The immediate problem is that + * it will be needing an expected tupdesc which we can't supply here. + * + * In the case where it has OUT parameters, it could get by without an + * expected tupdesc, but we still have issues: get_expr_result_type() + * doesn't know how to extract type info from a RECORD constant, and + * in the case of a NULL function result there doesn't seem to be any + * clean way to fix that. In view of the likelihood of there being + * still other gotchas, seems best to leave the function call unreduced. */ - if (funcform->prorettype == RECORDOID && - (heap_attisnull(func_tuple, Anum_pg_proc_proallargtypes) || - heap_attisnull(func_tuple, Anum_pg_proc_proargmodes))) + if (funcform->prorettype == RECORDOID) return NULL; /* diff --git a/src/backend/utils/fmgr/funcapi.c b/src/backend/utils/fmgr/funcapi.c index 43afc69322..b6ccd63d4d 100644 --- a/src/backend/utils/fmgr/funcapi.c +++ b/src/backend/utils/fmgr/funcapi.c @@ -7,7 +7,7 @@ * Copyright (c) 2002-2005, PostgreSQL Global Development Group * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/utils/fmgr/funcapi.c,v 1.23 2005/05/30 23:09:07 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/utils/fmgr/funcapi.c,v 1.24 2005/07/03 21:14:18 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -235,36 +235,6 @@ get_expr_result_type(Node *expr, NULL, resultTypeId, resultTupleDesc); - else if (expr && IsA(expr, Const) && - ((Const *) expr)->consttype == RECORDOID && - !((Const *) expr)->constisnull) - { - /* - * Pull embedded type info from a RECORD constant. We have to be - * prepared to handle this case in the wake of constant-folding of - * record-returning functions. - */ - HeapTupleHeader td; - int32 typmod; - - td = DatumGetHeapTupleHeader(((Const *) expr)->constvalue); - Assert(HeapTupleHeaderGetTypeId(td) == RECORDOID); - typmod = HeapTupleHeaderGetTypMod(td); - if (resultTypeId) - *resultTypeId = RECORDOID; - if (typmod >= 0) - { - if (resultTupleDesc) - *resultTupleDesc = lookup_rowtype_tupdesc(RECORDOID, typmod); - result = TYPEFUNC_COMPOSITE; - } - else - { - if (resultTupleDesc) - *resultTupleDesc = NULL; - result = TYPEFUNC_RECORD; - } - } else { /* handle as a generic expression; no chance to resolve RECORD */