mirror of
https://github.com/postgres/postgres.git
synced 2026-02-11 14:53:31 -05:00
f469f634ad
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. |
||
|---|---|---|
| .. | ||
| plpython_composite.sql | ||
| plpython_do.sql | ||
| plpython_drop.sql | ||
| plpython_error.sql | ||
| plpython_global.sql | ||
| plpython_import.sql | ||
| plpython_newline.sql | ||
| plpython_params.sql | ||
| plpython_populate.sql | ||
| plpython_quote.sql | ||
| plpython_record.sql | ||
| plpython_schema.sql | ||
| plpython_setof.sql | ||
| plpython_spi.sql | ||
| plpython_subtransaction.sql | ||
| plpython_test.sql | ||
| plpython_trigger.sql | ||
| plpython_types.sql | ||
| plpython_unicode.sql | ||
| plpython_void.sql | ||