]> granicus.if.org Git - postgresql/commit
Ensure plpgsql result tuples have the right composite type marking.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 3 Jul 2019 22:08:53 +0000 (18:08 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 3 Jul 2019 22:08:53 +0000 (18:08 -0400)
commit1dd8cf1b46a2e4ef68fc39771c21b8b737cf58b1
treeab7cd56cfeb6391b46eb6ec14222f9c240aa7e49
parent0cce43a716b40c555892b1d22b41d390ef524ec8
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
src/pl/plpgsql/src/expected/plpgsql_record.out
src/pl/plpgsql/src/pl_exec.c
src/pl/plpgsql/src/sql/plpgsql_record.sql