Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> I'm not trying to dismiss the importance of managing the Python
> transition. But this issue has been known for many years, and the
> current setup is more or less in line with the wider world. For
> example, the Debian release that came out over the weekend still ships
> with /usr/bin/python being Python 2. So it is neither timely nor urgent
> to try to make some significant change about this in PostgreSQL 12 right
> now. I would welcome patches for this for PostgreSQL 13.
I don't think it's been mentioned in this thread yet, but we *did*
recently install a configure-time preference for python3 over python2:
Author: Peter Eisentraut <pe...@eisentraut.org>
Branch: master Release: REL_12_BR [7291733ac] 2019-01-13 10:23:48 +0100
Branch: REL_11_STABLE Release: REL_11_2 [3d498c65a] 2019-01-13 10:24:21 +0100
Branch: REL_10_STABLE Release: REL_10_7 [cd1873160] 2019-01-13 10:25:23 +0100
configure: Update python search order
Some systems don't ship with "python" by default anymore, only
"python3" or "python2" or some combination, so include those in the
configure search.
Discussion:
https://www.postgresql.org/message-id/flat/1457.1543184081%40sss.pgh.pa.us#c9cc1199338fd6a257589c6dcea6cf8d
configure's search order is now $PYTHON, python, python3, python2.
I think it will be a very long time, if ever, before there would be
a reason to consider changing that. Both of the first two options
represent following a clear user preference.
So the only thing that's really at stake is when/whether we can make
"plpythonu" a synonym for "plpython3u" rather than "plpython2u".
As I said already, I think that's got to be a long way off, since the
whole problem here is that python3 isn't a drop-in replacement for
python2. We're much more likely to break existing functions than do
anything useful by forcibly switching the synonym.
But I could support having a way for individual installations to change
what the synonym means locally. Perhaps we could think about how to do
that in conjunction with the project of getting rid of pg_pltemplate
that's been kicked around before [1][2][3].
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/763f2fe4-743f-d530-8831-20811edd3d6a%402ndquadrant.com
[2] https://www.postgresql.org/message-id/flat/7495.1524861244%40sss.pgh.pa.us
[3]
https://www.postgresql.org/message-id/flat/5351890.TdMePpdHBD%40nb.usersys.redhat.com
