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

  1. Adjust PL/Tcl regression test to dodge a possible bug or zone dependency.