Ensure plpgsql result tuples have the right composite type marking.
A function that is declared to return a named composite type must
return tuple datums that are physically marked as having that type.
The plpgsql code path that allowed directly returning an expanded-record
datum forgot to check that, so that an expanded record marked as type
RECORDOID could be returned if it had a physically-compatible tupdesc.
This'd be harmless, I think, if the record value never escaped the
current session --- but it's possible for it to get stored into a table,
and then subsequent sessions can't interpret the anonymous record type.
Fix by flattening the record into a tuple datum and overwriting its
type/typmod fields, if its declared type doesn't match the function's
declared type. (In principle it might be possible to just change the
expanded record's stored type ID info, but there are enough tricky
consequences that I didn't want to mess with that, especially not in
a back-patched bug fix.)
Per bug report from Steve Rogerson. Back-patch to v11 where the bug
was introduced.
Discussion: https://postgr.es/m/cbaecae6-7b87-584e-45f6-4d047b92ca2a@yewtc.demon.co.uk
Branch
------
REL_11_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/24c5c711f497c995ad7b560aedd41b4d0f0f77f4
Modified Files
--------------
src/pl/plpgsql/src/expected/plpgsql_record.out | 13 +++++++++++++
src/pl/plpgsql/src/pl_exec.c | 25 +++++++++++++++++++++++++
src/pl/plpgsql/src/sql/plpgsql_record.sql | 10 ++++++++++
3 files changed, 48 insertions(+)