Horton

Re: Time to drop plpython2?

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2021-11-04T20:26:39Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> 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 think we want to keep plpython3u.  Maybe we can point plpythonu
at that, but I'm concerned about the potential for user confusion.
In particular, I think there's a nonzero probability that someone
will choose to maintain plpython2u/plpythonu outside of core,
just because they still don't want to migrate their Python code.

> 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?

Meh.  If there is a python 4, I'd expect it to be named that way precisely
because it *is* a breaking release.  Why would we set ourselves up for
a repeat of this mess?

			regards, tom lane

Commits

  1. plpython: add missing plpython.h include to plpy_plpymodule.h

  2. plpython: Adjust docs after removal of Python 2 support.

  3. plpython: Code cleanup related to removal of Python 2 support.

  4. plpython: Remove regression test infrastructure for Python 2.

  5. plpython: Remove plpythonu, plpython2u and associated transform extensions.

  6. plpython: Reject Python 2 during build configuration.

  7. Add traceback information to PL/Python errors