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:

Reply via email to