]> granicus.if.org Git - postgresql/commit
Ensure that whole-row junk Vars are always of composite type.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 28 Nov 2011 03:27:32 +0000 (22:27 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 28 Nov 2011 03:27:32 +0000 (22:27 -0500)
commit0702c86a13e6c644c32cf773af0a3a76e425ec50
tree5ec9f1e30d78a0589f95706c835dd0682f78260c
parentbcba9acf0d56d3fd5aa37c4ba6b24b6084032e58
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
src/backend/nodes/makefuncs.c
src/backend/optimizer/prep/preptlist.c
src/backend/parser/parse_expr.c
src/backend/rewrite/rewriteHandler.c
src/include/nodes/makefuncs.h