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
