Re: Resolving the python 2 -> python 3 mess

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

In response to

Responses

Browse pgsql-hackers by date

  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