pgsql: Fix plpython crash when returning string representation of a REC

Started by Tom Lanealmost 11 years ago1 messagescomitters
Jump to latest
#1Tom Lane
tgl@sss.pgh.pa.us

Fix plpython crash when returning string representation of a RECORD result.

PLyString_ToComposite() blithely overwrote proc->result.out.d, even though
for a composite result type the other union variant proc->result.out.r is
the one that should be valid. This could result in a crash if out.r had
in fact been filled in (proc->result.is_rowtype == 1) and then somebody
later attempted to use that data; as per bug #13579 from Paweł Michalak.

Just to add insult to injury, it didn't work for RECORD results anyway,
because record_in() would refuse the case.

Fix by doing the I/O function lookup in a local PLyTypeInfo variable,
as we were doing already in PLyObject_ToComposite(). This is not a great
technique because any fn_extra data allocated by the input function will
be leaked permanently (thanks to using TopMemoryContext as fn_mcxt).
But that's a pre-existing issue that is much less serious than a crash,
so leave it to be fixed separately.

This bug would be a potential security issue, except that plpython is
only available to superusers and the crash requires coding the function
in a way that didn't work before today's patches.

Add regression test cases covering all the supported methods of converting
composite results.

Back-patch to 9.1 where the faulty coding was introduced.

Branch
------
REL9_2_STABLE

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

Modified Files
--------------
src/pl/plpython/expected/plpython_composite.out | 206 +++++++++++++++++++++++
src/pl/plpython/plpy_typeio.c | 14 +-
src/pl/plpython/sql/plpython_composite.sql | 41 +++++
3 files changed, 259 insertions(+), 2 deletions(-)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers