Re: Resolving the python 2 -> python 3 mess

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Resolving the python 2 -> python 3 mess
Date: 2020-02-19 20:00:40
Message-ID: 7181.1582142440@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> 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.

Not really; use of the proposed porting infrastructure is the same whether
plpython2u still works or not. You end up with functions that are labeled
plpython3u, so what bare "plpythonu" means is not a factor.

It is true that as this patch is written, switching of plpythonu to
point at Python 3 rather than 2 is coupled to disabling plpython2u.
If we'd have gotten this done a year or two ago, I'd have made it more
complex to allow more separation there. But events have passed us by:
the info we are getting from packagers is that Python 2 is getting
dropped *this year*, not in some distant future. So I think that allowing
the plpythonu redefinition to be separate is no longer of any great value,
and not worth extra complication for. People are just going to be
shipping v13 with both things changed in any case.

If we wanted to do something to help people port their functions in
advance of the big changeover, the thing to do would be to back-patch
the proposed convert_python3 extension into existing branches.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-02-19 20:09:42 Re: Unicode normalization SQL functions
Previous Message Peter Eisentraut 2020-02-19 19:42:36 Re: Resolving the python 2 -> python 3 mess