plpythonu -> python3 - Mailing list pgsql-hackers

From Christoph Berg
Subject plpythonu -> python3
Date
Msg-id 20191107170431.GA27040@msg.df7cb.de
Whole thread Raw
Responses Re: plpythonu -> python3  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: plpythonu -> python3  (Patrik Novotny <panovotn@redhat.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: RFC: split OBJS lines to one object per line
Next
From: Mark Dilger
Date:
Subject: Re: Checking return value of SPI_execute