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
