Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit ae9a07b

Browse files
committed
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.
1 parent 85884cb commit ae9a07b

File tree

2 files changed

+12
-38
lines changed

2 files changed

+12
-38
lines changed

src/backend/optimizer/util/clauses.c

+11-7
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/optimizer/util/clauses.c,v 1.199 2005/06/26 22:05:38 tgl Exp $
11+
* $PostgreSQL: pgsql/src/backend/optimizer/util/clauses.c,v 1.200 2005/07/03 21:14:17 tgl Exp $
1212
*
1313
* HISTORY
1414
* AUTHOR DATE MAJOR EVENT
@@ -2200,13 +2200,17 @@ evaluate_function(Oid funcid, Oid result_type, List *args,
22002200
return NULL;
22012201

22022202
/*
2203-
* Can't simplify if it returns RECORD, except in the case where it has
2204-
* OUT parameters, since it will be needing an expected tupdesc which we
2205-
* can't supply here.
2203+
* Can't simplify if it returns RECORD. The immediate problem is that
2204+
* it will be needing an expected tupdesc which we can't supply here.
2205+
*
2206+
* In the case where it has OUT parameters, it could get by without an
2207+
* expected tupdesc, but we still have issues: get_expr_result_type()
2208+
* doesn't know how to extract type info from a RECORD constant, and
2209+
* in the case of a NULL function result there doesn't seem to be any
2210+
* clean way to fix that. In view of the likelihood of there being
2211+
* still other gotchas, seems best to leave the function call unreduced.
22062212
*/
2207-
if (funcform->prorettype == RECORDOID &&
2208-
(heap_attisnull(func_tuple, Anum_pg_proc_proallargtypes) ||
2209-
heap_attisnull(func_tuple, Anum_pg_proc_proargmodes)))
2213+
if (funcform->prorettype == RECORDOID)
22102214
return NULL;
22112215

22122216
/*

src/backend/utils/fmgr/funcapi.c

+1-31
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
* Copyright (c) 2002-2005, PostgreSQL Global Development Group
88
*
99
* IDENTIFICATION
10-
* $PostgreSQL: pgsql/src/backend/utils/fmgr/funcapi.c,v 1.23 2005/05/30 23:09:07 tgl Exp $
10+
* $PostgreSQL: pgsql/src/backend/utils/fmgr/funcapi.c,v 1.24 2005/07/03 21:14:18 tgl Exp $
1111
*
1212
*-------------------------------------------------------------------------
1313
*/
@@ -235,36 +235,6 @@ get_expr_result_type(Node *expr,
235235
NULL,
236236
resultTypeId,
237237
resultTupleDesc);
238-
else if (expr && IsA(expr, Const) &&
239-
((Const *) expr)->consttype == RECORDOID &&
240-
!((Const *) expr)->constisnull)
241-
{
242-
/*
243-
* Pull embedded type info from a RECORD constant. We have to be
244-
* prepared to handle this case in the wake of constant-folding of
245-
* record-returning functions.
246-
*/
247-
HeapTupleHeader td;
248-
int32 typmod;
249-
250-
td = DatumGetHeapTupleHeader(((Const *) expr)->constvalue);
251-
Assert(HeapTupleHeaderGetTypeId(td) == RECORDOID);
252-
typmod = HeapTupleHeaderGetTypMod(td);
253-
if (resultTypeId)
254-
*resultTypeId = RECORDOID;
255-
if (typmod >= 0)
256-
{
257-
if (resultTupleDesc)
258-
*resultTupleDesc = lookup_rowtype_tupdesc(RECORDOID, typmod);
259-
result = TYPEFUNC_COMPOSITE;
260-
}
261-
else
262-
{
263-
if (resultTupleDesc)
264-
*resultTupleDesc = NULL;
265-
result = TYPEFUNC_RECORD;
266-
}
267-
}
268238
else
269239
{
270240
/* handle as a generic expression; no chance to resolve RECORD */

0 commit comments

Comments
 (0)