Re: Resolving the python 2 -> python 3 mess - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Resolving the python 2 -> python 3 mess
Date
Msg-id 306e39e8-e9c9-5bf0-34a9-dcf35ca8fc39@2ndquadrant.com
Whole thread Raw
In response to Re: Resolving the python 2 -> python 3 mess  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Resolving the python 2 -> python 3 mess
List 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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Memory-Bounded Hash Aggregation
Next
From: Tom Lane
Date:
Subject: Re: Resolving the python 2 -> python 3 mess