Re: drop support for Python 2.3
Jim Nasby <jim.nasby@bluetreble.com>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-13T02:58:26Z
Lists: pgsql-hackers
On 2/7/17 10:49 PM, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> I would like to propose that we drop support for Python 2.3.
>> ...
>> We do have buildfarm coverage on prairiedog. However, that runs a >10
>> year old operating system, so I think it is not representing real usage.
> I have no particular objection to dropping 2.3 support, but should we
> make some effort to fail gracefully (ie, with a relevant error message)
> on older versions? I would guess that the effect of your patch will be
> to produce quite opaque failures. We seem to be computing python_version
> in configure, so it shouldn't be that hard to check.
Except AFAIK that won't protect the user if something on the OS changes
and backends suddenly start loading a 2.3 library, though I guess pl/tcl
suffers the same problem.
BTW, the easy way to check this (at least with cypthon) would be
PY_VERSION_HEX >= 0x02040000
(from cpython/include/patchlevel.h)
/* Version as a single 4-byte hex number, e.g. 0x010502B2 == 1.5.2b2.
Use this for numeric comparisons, e.g. #if PY_VERSION_HEX >= ... */
#define PY_VERSION_HEX ((PY_MAJOR_VERSION << 24) | \
(PY_MINOR_VERSION << 16) | \
(PY_MICRO_VERSION << 8) | \
(PY_RELEASE_LEVEL << 4) | \
(PY_RELEASE_SERIAL << 0))
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
Commits
-
Adjust PL/Tcl regression test to dodge a possible bug or zone dependency.
- 5b5b2fb4035d 9.2.21 landed
- dd2d437e8ee7 9.4.12 landed
- d27a48ad63f4 9.6.3 landed
- a8aeb871d914 9.5.7 landed
- 300ac7ff190f 9.3.17 landed
- 170511b30da4 10.0 landed