From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Resolving the python 2 -> python 3 mess |
Date: | 2020-02-19 19:42:36 |
Message-ID: | 306e39e8-e9c9-5bf0-34a9-dcf35ca8fc39@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-02-19 05:39, Tom Lane wrote:
> After thinking about this awhile longer, I'm starting to believe
> we should do some of each. That is, the stub replacement for
> plpython2.so should redirect "plpythonu" functions to plpython3.so,
> but throw errors for "plpython2u" functions.
I'm not sure these complications are worth it. They don't match
anything that is done in other Python 2/3 porting schemes. I think
there should just be an option "plpython is: {2|3|don't build it at
all}". Then packagers can match this to what their plan for
/usr/bin/python* is -- which appears to be different everywhere.
Your scheme appears to center around the assumption that people will
want to port their functions at the same time as not building plpython2u
anymore. This would defeat testing functions before and after in the
same installation. I think the decisions of what plpythonu points to
and which variants are built at all should be separate.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-02-19 20:00:40 | Re: Resolving the python 2 -> python 3 mess |
Previous Message | Tomas Vondra | 2020-02-19 19:16:36 | Re: Memory-Bounded Hash Aggregation |