mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Don't try to constant-fold functions returning RECORD. We were never

Browse Source 
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.
This commit is contained in:
Tom Lane 2005-07-03 21:14:18 +00:00
parent 85884cb1de
commit ae9a07bf9e
2 changed files with 12 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/backend/optimizer/util/clauses.c
View File

@ -8,7 +8,7 @@
* *
* *
* IDENTIFICATION * 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 * HISTORY
* AUTHOR DATE MAJOR EVENT * AUTHOR DATE MAJOR EVENT
@ -2200,13 +2200,17 @@ evaluate_function(Oid funcid, Oid result_type, List *args,
return NULL; return NULL;
/* /*
* Can't simplify if it returns RECORD, except in the case where it has * Can't simplify if it returns RECORD. The immediate problem is that
* OUT parameters, since it will be needing an expected tupdesc which we * it will be needing an expected tupdesc which we can't supply here.
* 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 && if (funcform->prorettype == RECORDOID)
(heap_attisnull(func_tuple, Anum_pg_proc_proallargtypes) ||
heap_attisnull(func_tuple, Anum_pg_proc_proargmodes)))
return NULL; return NULL;
/* /*

32
src/backend/utils/fmgr/funcapi.c
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.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, NULL,
resultTypeId, resultTypeId,
resultTupleDesc); 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 else
{ {
/* handle as a generic expression; no chance to resolve RECORD */ /* handle as a generic expression; no chance to resolve RECORD */