1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-12 21:01:52 +03:00

Ensure that whole-row junk Vars are always of composite type.

The EvalPlanQual machinery assumes that whole-row Vars generated for the
outputs of non-table RTEs will be of composite types.  However, for the
case where the RTE is a function call returning a scalar type, we were
doing the wrong thing, as a result of sharing code with a parser case
where the function's scalar output is wanted.  (Or at least, that's what
that case has done historically; it does seem a bit inconsistent.)

To fix, extend makeWholeRowVar's API so that it can support both use-cases.
This fixes Belinda Cussen's report of crashes during concurrent execution
of UPDATEs involving joins to the result of UNNEST() --- in READ COMMITTED
mode, we'd run the EvalPlanQual machinery after a conflicting row update
commits, and it was expecting to get a HeapTuple not a scalar datum from
the "wholerowN" variable referencing the function RTE.

Back-patch to 9.0 where the current EvalPlanQual implementation appeared.

In 9.1 and up, this patch also fixes failure to attach the correct
collation to the Var generated for a scalar-result case.  An example:
regression=# select upper(x.*) from textcat('ab', 'cd') x;
ERROR:  could not determine which collation to use for upper() function
This commit is contained in:
Tom Lane
2011-11-27 22:27:24 -05:00
parent 91572ee0a6
commit dd3bab5fd7
5 changed files with 38 additions and 27 deletions

View File

@ -121,11 +121,17 @@ makeVarFromTargetEntry(Index varno,
* with error cases, but it's not worth changing now.) The vartype indicates
* a rowtype; either a named composite type, or RECORD. This function
* encapsulates the logic for determining the correct rowtype OID to use.
*
* If allowScalar is true, then for the case where the RTE is a function
* returning a non-composite result type, we produce a normal Var referencing
* the function's result directly, instead of the single-column composite
* value that the whole-row notation might otherwise suggest.
*/
Var *
makeWholeRowVar(RangeTblEntry *rte,
Index varno,
Index varlevelsup)
Index varlevelsup,
bool allowScalar)
{
Var *result;
Oid toid;
@ -157,39 +163,34 @@ makeWholeRowVar(RangeTblEntry *rte,
InvalidOid,
varlevelsup);
}
else
else if (allowScalar)
{
/*
* func returns scalar; instead of making a whole-row Var,
* just reference the function's scalar output. (XXX this
* seems a tad inconsistent, especially if "f.*" was
* explicitly written ...)
*/
/* func returns scalar; just return its output as-is */
result = makeVar(varno,
1,
toid,
-1,
exprCollation(rte->funcexpr),
varlevelsup);
}
else
{
/* func returns scalar, but we want a composite result */
result = makeVar(varno,
InvalidAttrNumber,
RECORDOID,
-1,
InvalidOid,
varlevelsup);
}
break;
case RTE_VALUES:
toid = RECORDOID;
/* returns composite; same as relation case */
result = makeVar(varno,
InvalidAttrNumber,
toid,
-1,
InvalidOid,
varlevelsup);
break;
default:
/*
* RTE is a join or subselect. We represent this as a whole-row
* Var of RECORD type. (Note that in most cases the Var will be
* expanded to a RowExpr during planning, but that is not our
* concern here.)
* RTE is a join, subselect, or VALUES. We represent this as a
* whole-row Var of RECORD type. (Note that in most cases the Var
* will be expanded to a RowExpr during planning, but that is not
* our concern here.)
*/
result = makeVar(varno,
InvalidAttrNumber,