Re: Time to drop plpython2?
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers@postgresql.org
Date: 2021-11-04T19:54:43Z
Lists: pgsql-hackers
Hi, On 2021-11-04 19:58:54 +0100, Peter Eisentraut wrote: > I see you have posted a patch for this in the meson thread (https://www.postgresql.org/message-id/attachment/127770/v5-0003-plpython-Drop-support-python2.patch). Yea, I was planning to post that here after a bit more polish. I mostly wanted to get rid of the gross gross hack I did for the transmutation of the regression test files. > Here is my review of that. > > I would change the search order in configure from > > PGAC_PATH_PROGS(PYTHON, [python python3 python2]) > to > > PGAC_PATH_PROGS(PYTHON, [python3 python]) > > This makes sure you don't accidentally pick up a "python" binary that points > to Python 2. This would otherwise immediately generate lots of build > failures on older platforms that still have Python 2 around. Yes, we should do that, at least for now. I did see build failures that required me to specify the python version to avoid issues around it. > You left two FIXME sections in plpython.h. AFAICT, we can make the > substitutions corresponding to those #define's in the source code and remove > those blocks. Yea, it shouldn't be hard. Just required more time than I had to send it out before Nov 1st ;) With meson I'd do a version: '>= 3' or such, to filter out a bare 'python' being python2, but I don't think there's an equally trivial way to do that with autoconf. > Finally, morally related, there is some Python 2/3 compat code in > contrib/unaccent/generate_unaccent_rules.py that could be removed. Also, > arguably, change the shebang line in that script. Hm. So far the python used for plpython and python for code generation etc is independent. I don't know if plpython actually can be cross-compiled, but if so, they'd have to be independent. Otherwise I'd say we should just invoke contrib/unaccent/generate_unaccent_rules.py with a python chosen by configure/meson, rather than relying on a shebang that can't be adjusted without modifying source code. Another thing I wondered about is what we want to do with the extension names. Do we want to leave it named plpython3u? Do we want to have a plpython that depends on plpython3u? I'd be inclined to just keep it at plpython3u for now, but there's an argument that going for plpython would be better long term: Presumably there will be python 4 at some point - but I'd expect that to not be a breaking release, given the disaster that python 3 is. Making a non-versioned name better? Greetings, Andres Freund
Commits
-
plpython: add missing plpython.h include to plpy_plpymodule.h
- 54c72eb5e5e6 15.0 landed
-
plpython: Adjust docs after removal of Python 2 support.
- 4228cabb72bb 15.0 landed
-
plpython: Code cleanup related to removal of Python 2 support.
- 9b7e24a2cb37 15.0 landed
-
plpython: Remove regression test infrastructure for Python 2.
- db23464715f4 15.0 landed
-
plpython: Remove plpythonu, plpython2u and associated transform extensions.
- 76a29adee749 15.0 landed
-
plpython: Reject Python 2 during build configuration.
- 19252e8ec938 15.0 landed
-
Add traceback information to PL/Python errors
- 2bd78eb8d51c 9.1.0 cited