mirror of
https://github.com/postgres/postgres.git
synced 2026-06-08 08:34:03 -04:00
Peter Eisentraut
ba3e4157a7
Before 9.1, PL/Python functions returning composite types could return a string and it would be parsed using record_in. The 9.1 changes made PL/Python only expect dictionaries, tuples, or objects supporting getattr as output of composite functions, resulting in a regression and a confusing error message, as the strings were interpreted as sequences and the code for transforming lists to database tuples was used. Fix this by treating strings separately as before, before checking for the other types. The reason why it's important to support string to database tuple conversion is that trigger functions on tables with composite columns get the composite row passed in as a string (from record_out). Without supporting converting this back using record_in, this makes it impossible to implement pass-through behavior for these columns, as PL/Python no longer accepts strings for composite values. A better solution would be to fix the code that transforms composite inputs into Python objects to produce dictionaries that would then be correctly interpreted by the Python->PostgreSQL counterpart code. But that would be too invasive to backpatch to 9.1, and it is too late in the 9.2 cycle to attempt it. It should be revisited in the future, though. Reported as bug #6559 by Kirill Simonov. Jan Urbański
Guide to alternative expected files: plpython_error_0.out Python 2.4 and older plpython_unicode.out server encoding != SQL_ASCII plpython_unicode_3.out server encoding == SQL_ASCII plpython_subtransaction_0.out Python 2.4 and older (without with statement) plpython_subtransaction_5.out Python 2.5 (without with statement) plpython_types_3.out Python 3.x Note: Building with Python 2.2 is supported, but there are no expected files for it (too much work to maintain).