Re: Time to drop plpython2?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Time to drop plpython2?
Дата
Msg-id 20211104195443.dystyijvufveikcp@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Time to drop plpython2?  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Time to drop plpython2?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Time to drop plpython2?  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
Hi,

On 2021-11-04 19:58:54 +0100, Peter Eisentraut wrote:
> I see you have posted a patch for this in the meson thread
(https://www.postgresql.org/message-id/attachment/127770/v5-0003-plpython-Drop-support-python2.patch).

Yea, I was planning to post that here after a bit more polish. I mostly wanted
to get rid of the gross gross hack I did for the transmutation of the
regression test files.


> Here is my review of that.
> 
> I would change the search order in configure from
> 
> PGAC_PATH_PROGS(PYTHON, [python python3 python2])

> to
> 
> PGAC_PATH_PROGS(PYTHON, [python3 python])
> 
> This makes sure you don't accidentally pick up a "python" binary that points
> to Python 2.  This would otherwise immediately generate lots of build
> failures on older platforms that still have Python 2 around.

Yes, we should do that, at least for now. I did see build failures that
required me to specify the python version to avoid issues around it.


> You left two FIXME sections in plpython.h.  AFAICT, we can make the
> substitutions corresponding to those #define's in the source code and remove
> those blocks.

Yea, it shouldn't be hard. Just required more time than I had to send it out
before Nov 1st ;)

With meson I'd do a version: '>= 3' or such, to filter out a bare 'python'
being python2, but I don't think there's an equally trivial way to do that
with autoconf.


> Finally, morally related, there is some Python 2/3 compat code in
> contrib/unaccent/generate_unaccent_rules.py that could be removed. Also,
> arguably, change the shebang line in that script.

Hm. So far the python used for plpython and python for code generation etc is
independent. I don't know if plpython actually can be cross-compiled, but if
so, they'd have to be independent.  Otherwise I'd say we should just invoke
contrib/unaccent/generate_unaccent_rules.py with a python chosen by
configure/meson, rather than relying on a shebang that can't be adjusted
without modifying source code.


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

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: parallel vacuum comments
Следующее
От: Andres Freund
Дата:
Сообщение: Re: should we enable log_checkpoints out of the box?