On 2/10/16 12:44 PM, Pavel Stehule wrote:
FWIW, I'd think it's better to not break backwards compatibility, but I'm also far from a python expert. It might well be worth adding a plpython GUC to control the behavior so that there's a migration path forward, or maybe do something like the 'import __future__' that python is doing to ease migration to python 3. Iacob is maybe little bit too defensive - but why not. The implementation of GUC should not be hard. I see it as best way now. Tomorrow I'll try to find last versions of this patch in mailbox and try to design compatibility mode.
BTW, there's other cases where we're going to face this compatibility issue. The one I know of right now is that current handling of composite types containing arrays in plpython sucks, but there's no way to change that without breaking compatibility.
I don't see any good way to handle these compatibility things other than giving each one its own pl-specific GUC, but I figured I'd at least mention it.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers