Re: Time to drop plpython2?
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2022-03-08T01:00:07Z
Lists: pgsql-hackers
Attachments
Hi, On 2022-03-07 15:05:03 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Now that the BF has stabilized, I've rebased and cleaned up the patches I'd > > posted earlier. Attached for the first time is my attempt at cleaning up the > > docs. > > I looked through this quickly, and have a couple of nitpicks. The > PGFILEDESC value for jsonb_plpython is worded randomly differently > from those for hstore_plpython and ltree_plpython. I think we should > make it match those. Makes sense. > I also noted a couple of typos in the docs patch. > See attached delta patch Thanks, incorporated. > I kind of wonder if we still need "46.1. Python 2 vs. Python 3" at > all. It certainly doesn't seem like it still deserves its position > of honor as the first subsection. Perhaps move it down to be the > last subsection? Agreed. I think it's useful to have it, just so we have a place mentioning plpython[2]u. I put it as the second last subsection for now, somehow seemed to belong before the env variable list? But... > Also, grepping reveals that vcregress.pl still has two stray references to > "plpythonu". I left that in somewhat intentionally, it seemed the cleanest way to remove plpython2 from vcregress.pl. It's purely cosmetic afaics. A related question is whether we want to remove $(python_majorversion) references in the makefiles? > I did not touch that here, but maybe that has something to do with the ci > failure? The CI failure was caused by me screwing up search and replace :(. Accidentally replaced PyString_AsString with PyUnicode_AsString instead of P*L*yUnicode_AsString. Somewhat surprised at that causing problems only on windows (even valgrind didn't, although the required suppressions might have been the cause of that). But well, better there than nowhere... > > I did so far leave in the "major version conflict" detection stuff in > > plpy_main.c - that could again be useful? I'm leaning towards removing it, I'd > > hope that there's not again such a painful transition, and we have the git > > history if needed. > > I think we should leave it in. I foresee that somebody will want to build > plpython2u as an out-of-core extension, at least for a few years yet. > If they do, and the core language does not have its half of that guard, > it'd be bad. Makes sense. Added a comment to that effect. I noticed a few references to PLyString in function names. Probably should replace them with PLyUnicode. Didn't do that yet in the attached... 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