pgsql: Fix failure to cover scalar-vs-rowtype cases in exec_stmt_return

Fix failure to cover scalar-vs-rowtype cases in exec_stmt_return().

In commit 9e3ad1aac52454569393a947c06be0d301749362 I modified plpgsql
to use exec_stmt_return's simple-variables fast path in more cases.
However, I overlooked that there are really two different return
conventions in use here, depending on whether estate->retistuple is true,
and the existing fast-path code had only bothered to handle one of them.
So trying to return a scalar in a function returning composite, or vice
versa, could lead to unexpected error messages (typically "cache lookup
failed for type 0") or to a null-pointer-dereference crash.

In the DTYPE_VAR case, we can just throw error if retistuple is true,
corresponding to what happens in the general-expression code path that was
being used previously.  (Perhaps someday both of these code paths should
attempt a coercion, but today is not that day.)

In the REC and ROW cases, just hand the problem to exec_eval_datum()
when not retistuple.  Also clean up the ROW coding slightly so it looks
more like exec_eval_datum().

The previous commit also caused exec_stmt_return_next() to be used in
more cases, but that code seems to be OK as-is.

Per off-list report from Serge Rielau.  This bug is new in 9.5 so no need
to back-patch.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/ae58f1430abb4b0c309c40b377f91bf9d080334b

Modified Files
--------------
src/pl/plpgsql/src/pl_exec.c          |   58 ++++++++++++++++++++++++++-------
src/test/regress/expected/plpgsql.out |   32 ++++++++++++++++++
src/test/regress/sql/plpgsql.sql      |   33 +++++++++++++++++++
3 files changed, 112 insertions(+), 11 deletions(-)