plpythonu -> python3

Поиск
Список
Период
Сортировка
От Christoph Berg
Тема plpythonu -> python3
Дата
Msg-id 20191107170431.GA27040@msg.df7cb.de
обсуждение исходный текст
Ответы Re: plpythonu -> python3  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: plpythonu -> python3  (Patrik Novotny <panovotn@redhat.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: RFC: split OBJS lines to one object per line
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: Checking return value of SPI_execute