Thread: plpythonu -> python3
The docs currently say
The language named <literal>plpythonu</literal> implements
PL/Python based on the default Python language variant, which is
currently Python 2. (This default is independent of what any
local Python installations might consider to be
their <quote>default</quote>, for example,
what <filename>/usr/bin/python</filename> might be.) The
default will probably be changed to Python 3 in a distant future
release of PostgreSQL, depending on the progress of the
migration to Python 3 in the Python community.
As python2 is EOL very soon, I'd say that point is now, i.e. we should
make plpythonu.control point at plpython3u in PG13+. And probably drop
python2 support altogether.
For PG12, I have the problem that I don't want to keep supporting
python2 (Debian is already working hard on removing all python2
references), and have therefore already disabled building the
plpython2 packages for Debian, shipping only plpython3.
PostGIS developer Raúl Marín has rightfully noticed that this leaves
us without the "plpythonu" extension, forcing everyone to move to
"plpython3u" even when their code works with both.
How do other packagers handle that? Are you still supporting python2?
Would it be ok to make plpythonu.control point at python3 in PG12 in
Debian, even the upstream default is still python2?
Christoph
Christoph Berg <myon@debian.org> writes:
> The docs currently say
> The language named <literal>plpythonu</literal> implements
> PL/Python based on the default Python language variant, which is
> currently Python 2. (This default is independent of what any
> local Python installations might consider to be
> their <quote>default</quote>, for example,
> what <filename>/usr/bin/python</filename> might be.) The
> default will probably be changed to Python 3 in a distant future
> release of PostgreSQL, depending on the progress of the
> migration to Python 3 in the Python community.
> As python2 is EOL very soon, I'd say that point is now, i.e. we should
> make plpythonu.control point at plpython3u in PG13+.
We're starting to work on that; it's not a trivial change. Among other
things, pg_pltemplate has got pointers at plpython2 as well. See [1]
for one preliminary step, and there are other discussions in the archives
about things we could do to make this smoother.
> And probably drop python2 support altogether.
I think it'll be quite some time before that happens. People who
are still using ancient versions of Postgres are not likely to be
impressed by arguments about how python2 is out of support.
> For PG12, I have the problem that I don't want to keep supporting
> python2 (Debian is already working hard on removing all python2
> references), and have therefore already disabled building the
> plpython2 packages for Debian, shipping only plpython3.
You're fully within your rights to stop building plpython2 in what you
ship. That's not an argument for removing the upstream support.
> Would it be ok to make plpythonu.control point at python3 in PG12 in
> Debian, even the upstream default is still python2?
I do not think you should do that. This transition is going to be
painful enough without distributions making their own ad-hoc changes
that are different from what other people are doing.
Right at the moment, given that Debian and others have already stopped
shipping "/usr/bin/python", I'd say that the equivalent thing is just to
stop building plpython2, and force users to deal with the change manually.
If you didn't decide to symlink /usr/bin/python to python3 instead of
python2, what's the justification for doing the moral equivalent of that
with plpython?
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/5889.1566415762@sss.pgh.pa.us
Re: Tom Lane 2019-11-07 <14186.1573147925@sss.pgh.pa.us> > > And probably drop python2 support altogether. > > I think it'll be quite some time before that happens. People who > are still using ancient versions of Postgres are not likely to be > impressed by arguments about how python2 is out of support. Fwiw, I meant to suggest dropping python2 support in PG13+. (At the moment there are some "interesting" scripts in src/pl/plpython that convert the plpython2 things on the fly to be python3 compatible, these could go away, simplifying some parts of the build system.) Christoph
On Thu, Nov 7, 2019 at 6:04 PM Christoph Berg <myon@debian.org> wrote: > How do other packagers handle that? Are you still supporting python2? > Would it be ok to make plpythonu.control point at python3 in PG12 in > Debian, even the upstream default is still python2? Speaking for Fedora and RHEL, I'd say the best way to approach this from the packager standpoint would be to simply stop building plpython2 for releases without python2 support. > Would it be ok to make plpythonu.control point at python3 in PG12 in > Debian, even the upstream default is still python2? IMHO, this should be done upstream. The reason for this would be to have a uniform approach to this across distributions, and it is explained in more detail in some of the older threads of this list. -- Patrik Novotný Associate Software Engineer Red Hat panovotn@redhat.com
I wrote: > Christoph Berg <myon@debian.org> writes: >> As python2 is EOL very soon, I'd say that point is now, i.e. we should >> make plpythonu.control point at plpython3u in PG13+. > We're starting to work on that; it's not a trivial change. Among other > things, pg_pltemplate has got pointers at plpython2 as well. See [1] > for one preliminary step, and there are other discussions in the archives > about things we could do to make this smoother. Some of that prior discussion is here: https://www.postgresql.org/message-id/flat/5351890.TdMePpdHBD%40nb.usersys.redhat.com One thing that'd be useful to do, perhaps, is polish up the conversion script I posted in that thread, and make it available to users before plpython2 disappears. (As written, it needs both plpython versions to be available ...) regards, tom lane