drop support for Python 2.3
I would like to propose that we drop support for Python 2.3. Reasons:
- Python 3.6 was released in December. The list of versions we need to
manage is growing.
- Older Python versions are increasingly hard to build locally for testing.
- It's unlikely that Python 2.3 is still used in practice. Python 2.4
is in RHEL 5, which is the typically the oldest mainstream OS we look at.
- We could remove some cruft from the code.
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.
Patch attached.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Drop-support-for-Python-2.3.patchtext/x-patch; name=0001-Drop-support-for-Python-2.3.patchDownload
From 94592edd240680224e5a971e8be7a5127f193d0c Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 16 Aug 2016 12:00:00 -0400
Subject: [PATCH] Drop support for Python 2.3
---
.../hstore_plpython/expected/hstore_plpython.out | 8 ++------
contrib/hstore_plpython/sql/hstore_plpython.sql | 8 ++------
doc/src/sgml/installation.sgml | 6 +-----
src/pl/plpython/expected/plpython_ereport.out | 24 +++++++++-------------
src/pl/plpython/plpy_typeio.c | 10 ++-------
src/pl/plpython/sql/plpython_ereport.sql | 8 ++------
6 files changed, 19 insertions(+), 45 deletions(-)
diff --git a/contrib/hstore_plpython/expected/hstore_plpython.out b/contrib/hstore_plpython/expected/hstore_plpython.out
index b0025c04a8..df49cd5f37 100644
--- a/contrib/hstore_plpython/expected/hstore_plpython.out
+++ b/contrib/hstore_plpython/expected/hstore_plpython.out
@@ -6,9 +6,7 @@ LANGUAGE plpythonu
TRANSFORM FOR TYPE hstore
AS $$
assert isinstance(val, dict)
-i = list(val.items())
-i.sort()
-plpy.info(i)
+plpy.info(sorted(val.items()))
return len(val)
$$;
SELECT test1('aa=>bb, cc=>NULL'::hstore);
@@ -24,9 +22,7 @@ LANGUAGE plpython2u
TRANSFORM FOR TYPE hstore
AS $$
assert isinstance(val, dict)
-i = list(val.items())
-i.sort()
-plpy.info(i)
+plpy.info(sorted(val.items()))
return len(val)
$$;
SELECT test1n('aa=>bb, cc=>NULL'::hstore);
diff --git a/contrib/hstore_plpython/sql/hstore_plpython.sql b/contrib/hstore_plpython/sql/hstore_plpython.sql
index d55bedaf50..911bbd67fe 100644
--- a/contrib/hstore_plpython/sql/hstore_plpython.sql
+++ b/contrib/hstore_plpython/sql/hstore_plpython.sql
@@ -7,9 +7,7 @@ CREATE FUNCTION test1(val hstore) RETURNS int
TRANSFORM FOR TYPE hstore
AS $$
assert isinstance(val, dict)
-i = list(val.items())
-i.sort()
-plpy.info(i)
+plpy.info(sorted(val.items()))
return len(val)
$$;
@@ -22,9 +20,7 @@ CREATE FUNCTION test1n(val hstore) RETURNS int
TRANSFORM FOR TYPE hstore
AS $$
assert isinstance(val, dict)
-i = list(val.items())
-i.sort()
-plpy.info(i)
+plpy.info(sorted(val.items()))
return len(val)
$$;
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index 4431ed75a9..231d9dea4a 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -193,11 +193,7 @@ <title>Requirements</title>
language, you need a <productname>Python</productname>
installation with the header files and
the <application>distutils</application> module. The minimum
- required version is <productname>Python</productname> 2.3.
- (To work with function arguments of type <type>numeric</>, a 2.3.x
- installation must include the separately-available <filename>cdecimal</>
- module; note the <application>PL/Python</> regression tests
- will not pass if that is missing.)
+ required version is <productname>Python</productname> 2.4.
<productname>Python 3</productname> is supported if it's
version 3.1 or later; but see
<![%standalone-include[the <application>PL/Python</> documentation]]>
diff --git a/src/pl/plpython/expected/plpython_ereport.out b/src/pl/plpython/expected/plpython_ereport.out
index 13bd0ab335..1dafd94c72 100644
--- a/src/pl/plpython/expected/plpython_ereport.out
+++ b/src/pl/plpython/expected/plpython_ereport.out
@@ -94,26 +94,22 @@ kwargs = {
"column_name": _column_name, "datatype_name": _datatype_name,
"constraint_name": _constraint_name
}
-# ignore None values - should work on Python2.3
-dict = {}
-for k in kwargs:
- if kwargs[k] is not None:
- dict[k] = kwargs[k]
-plpy.error(**dict)
+# ignore None values
+plpy.error(**dict((k, v) for k, v in iter(kwargs.items()) if v))
$$ LANGUAGE plpythonu;
SELECT raise_exception('hello', 'world');
ERROR: plpy.Error: hello
DETAIL: world
CONTEXT: Traceback (most recent call last):
- PL/Python function "raise_exception", line 13, in <module>
- plpy.error(**dict)
+ PL/Python function "raise_exception", line 9, in <module>
+ plpy.error(**dict((k, v) for k, v in iter(kwargs.items()) if v))
PL/Python function "raise_exception"
SELECT raise_exception('message text', 'detail text', _sqlstate => 'YY333');
ERROR: plpy.Error: message text
DETAIL: detail text
CONTEXT: Traceback (most recent call last):
- PL/Python function "raise_exception", line 13, in <module>
- plpy.error(**dict)
+ PL/Python function "raise_exception", line 9, in <module>
+ plpy.error(**dict((k, v) for k, v in iter(kwargs.items()) if v))
PL/Python function "raise_exception"
SELECT raise_exception(_message => 'message text',
_detail => 'detail text',
@@ -128,8 +124,8 @@ ERROR: plpy.Error: message text
DETAIL: detail text
HINT: hint text
CONTEXT: Traceback (most recent call last):
- PL/Python function "raise_exception", line 13, in <module>
- plpy.error(**dict)
+ PL/Python function "raise_exception", line 9, in <module>
+ plpy.error(**dict((k, v) for k, v in iter(kwargs.items()) if v))
PL/Python function "raise_exception"
SELECT raise_exception(_message => 'message text',
_hint => 'hint text',
@@ -139,8 +135,8 @@ SELECT raise_exception(_message => 'message text',
ERROR: plpy.Error: message text
HINT: hint text
CONTEXT: Traceback (most recent call last):
- PL/Python function "raise_exception", line 13, in <module>
- plpy.error(**dict)
+ PL/Python function "raise_exception", line 9, in <module>
+ plpy.error(**dict((k, v) for k, v in iter(kwargs.items()) if v))
PL/Python function "raise_exception"
DO $$
DECLARE
diff --git a/src/pl/plpython/plpy_typeio.c b/src/pl/plpython/plpy_typeio.c
index b9c6d64baa..06743e46ed 100644
--- a/src/pl/plpython/plpy_typeio.c
+++ b/src/pl/plpython/plpy_typeio.c
@@ -521,15 +521,9 @@ PLy_input_datum_func2(PLyDatumToOb *arg, MemoryContext arg_mcxt, Oid typeOid, He
static PyObject *
PLyBool_FromBool(PLyDatumToOb *arg, Datum d)
{
- /*
- * We would like to use Py_RETURN_TRUE and Py_RETURN_FALSE here for
- * generating SQL from trigger functions, but those are only supported in
- * Python >= 2.4, and we support older versions.
- * http://docs.python.org/api/boolObjects.html
- */
if (DatumGetBool(d))
- return PyBool_FromLong(1);
- return PyBool_FromLong(0);
+ Py_RETURN_TRUE;
+ Py_RETURN_FALSE;
}
static PyObject *
diff --git a/src/pl/plpython/sql/plpython_ereport.sql b/src/pl/plpython/sql/plpython_ereport.sql
index 2612e93387..889293d33c 100644
--- a/src/pl/plpython/sql/plpython_ereport.sql
+++ b/src/pl/plpython/sql/plpython_ereport.sql
@@ -55,12 +55,8 @@ CREATE OR REPLACE FUNCTION raise_exception(_message text, _detail text DEFAULT N
"column_name": _column_name, "datatype_name": _datatype_name,
"constraint_name": _constraint_name
}
-# ignore None values - should work on Python2.3
-dict = {}
-for k in kwargs:
- if kwargs[k] is not None:
- dict[k] = kwargs[k]
-plpy.error(**dict)
+# ignore None values
+plpy.error(**dict((k, v) for k, v in iter(kwargs.items()) if v))
$$ LANGUAGE plpythonu;
SELECT raise_exception('hello', 'world');
--
2.11.1
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.
- It's unlikely that Python 2.3 is still used in practice. Python 2.4
is in RHEL 5, which is the typically the oldest mainstream OS we look at.
Hm, is there anything running 2.4 in the buildfarm? If we're going to
claim support for 2.4, we'd be well advised to test it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/7/17 11:49 PM, Tom Lane wrote:
Hm, is there anything running 2.4 in the buildfarm? If we're going to
claim support for 2.4, we'd be well advised to test it.
It appears that we don't have anything running 2.4. A RHEL/CentOS 5
system with standard components would be a good addition to the build farm.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On Wed, 2017-02-08 at 09:16 -0500, Peter Eisentraut wrote:
It appears that we don't have anything running 2.4. A RHEL/CentOS 5
system with standard components would be a good addition to the build farm.
I have CentOS 5 instances running on buildfarm. I'll register them via
buildfarm.pg.org soon.
Regards,
--
Devrim Gündüz
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
On 02/07/2017 11: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.- It's unlikely that Python 2.3 is still used in practice. Python 2.4
is in RHEL 5, which is the typically the oldest mainstream OS we look at.Hm, is there anything running 2.4 in the buildfarm? If we're going to
claim support for 2.4, we'd be well advised to test it.
with top as (select distinct on (sysname) sysname, snapshot from
build_status_recent_500 where branch = 'HEAD' order by sysname,
snapshot desc ) select * from top where exists (select 1 from
build_status_log l where l.sysname = top.sysname and l.snapshot =
top.snapshot and l.branch = 'HEAD' and l.log_stage = 'config.log'
and l.log_text ~ 'python2\.4');
This returns no rows.
Maybe we need to set up a Centos5 or RHEL 5 animal.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/8/17 10:35, Devrim Gündüz wrote:
On Wed, 2017-02-08 at 09:16 -0500, Peter Eisentraut wrote:
It appears that we don't have anything running 2.4. A RHEL/CentOS 5
system with standard components would be a good addition to the build farm.I have CentOS 5 instances running on buildfarm. I'll register them via
buildfarm.pg.org soon.
I will wait for that before proceeding.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Peter,
On Thu, 2017-02-16 at 08:21 -0500, Peter Eisentraut wrote:
I have CentOS 5 instances running on buildfarm. I'll register them via
buildfarm.pg.org soon.I will wait for that before proceeding.
Sorry for the delay. Machines are ready, I think I can prepare the buildfarm
instances later Saturday.
Regards,
--
Devrim Gündüz
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
Hi,
On Thu, 2017-02-16 at 08:21 -0500, Peter Eisentraut wrote:
I will wait for that before proceeding.
Sorry for the delay, I also had to build a newer flex RPM before proceeding.
arapaima(x86) and aholehole(x86_64) are the new animals. They are running the
buildfarm script now.
Regards,
--
Devrim Gündüz
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= <devrim@gunduz.org> writes:
arapaima(x86) and aholehole(x86_64) are the new animals. They are running the
buildfarm script now.
... and failing. I wonder what is wrong with tcl_date_week()?
Will look for the explanation in a bit.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= <devrim@gunduz.org> writes:
arapaima(x86) and aholehole(x86_64) are the new animals. They are running the
buildfarm script now.
... and failing. I wonder what is wrong with tcl_date_week()?
Will look for the explanation in a bit.
Relevant question: what version of tcl is installed on those?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Tom,
On Sun, 2017-02-19 at 10:42 -0500, Tom Lane wrote:
Relevant question: what version of tcl is installed on those?
8.4.13 is installed.
Regards,
--
Devrim Gündüz
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= <devrim@gunduz.org> writes:
On Sun, 2017-02-19 at 10:42 -0500, Tom Lane wrote:
Relevant question: what version of tcl is installed on those?
8.4.13 is installed.
Hmph. I can't see any relevant-looking source changes between 8.4.13
and 8.4.15, which I have laying about here and which works fine.
I wonder if Red Hat is carrying some distro-specific patch that
breaks this case? Or conceivably it's timezone dependent?
Anyway, my inclination is just to tweak that test a bit so it doesn't
trip over the problem. The point of the test is mainly to see if the
[clock] command works at all, not to exercise any specific parameter
choices. Would you check whether this:
$ tclsh
% clock format [clock scan "1/26/2010"] -format "%U"
gives the expected result "04" on that machine?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Tom,
On Sun, 2017-02-19 at 13:48 -0500, Tom Lane wrote:
Hmph. I can't see any relevant-looking source changes between 8.4.13
and 8.4.15, which I have laying about here and which works fine.
I wonder if Red Hat is carrying some distro-specific patch that
breaks this case?
Just downloaded SRPM, and I don't *think* so their patch would break this.
Or conceivably it's timezone dependent?
FWIW, the timezone of the server is GMT+3, if that is what you are asking.
Anyway, my inclination is just to tweak that test a bit so it doesn't
trip over the problem. The point of the test is mainly to see if the
[clock] command works at all, not to exercise any specific parameter
choices. Would you check whether this:$ tclsh
% clock format [clock scan "1/26/2010"] -format "%U"gives the expected result "04" on that machine?
Yes, I got 04.
Regards,
--
Devrim Gündüz
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= <devrim@gunduz.org> writes:
On Sun, 2017-02-19 at 13:48 -0500, Tom Lane wrote:
Or conceivably it's timezone dependent?
FWIW, the timezone of the server is GMT+3, if that is what you are asking.
Well, that test is checking which week-of-the-year a Sunday midnight is
considered to fall into. There could be an edge-case bug in Tcl itself,
or a problem with the time zone data, or maybe if you're setting LC_TIME
to tr_TR, that changes whether weeks are considered to start on Sunday
or Monday? Although if that were the explanation I'd have expected this
test to fail in tr_TR locale on pretty much any platform. Weird.
Whatever, even if it's a bug it's not our bug. I've adjusted the test to
check the following Tuesday, so as to dodge the edge case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On Sun, 2017-02-19 at 16:20 -0500, Tom Lane wrote:
Well, that test is checking which week-of-the-year a Sunday midnight is
considered to fall into. There could be an edge-case bug in Tcl itself,
or a problem with the time zone data, or maybe if you're setting LC_TIME
to tr_TR, that changes whether weeks are considered to start on Sunday
or Monday? Although if that were the explanation I'd have expected this
test to fail in tr_TR locale on pretty much any platform. Weird.
All LC_* settings are en_GB.UTF-8 on this server.
Whatever, even if it's a bug it's not our bug. I've adjusted the test to
check the following Tuesday, so as to dodge the edge case.
Thanks! Looks like buildfarm is green again.
Regards,
--
Devrim Gündüz
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
On 2/19/17 23:33, Devrim Gündüz wrote:
Thanks! Looks like buildfarm is green again.
Thank. I have committed the patch to drop Python 2.3 support.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 2/19/17 23:33, Devrim Gündüz wrote:
Thanks! Looks like buildfarm is green again.
Thank. I have committed the patch to drop Python 2.3 support.
I spent some time last night building a (rather makeshift) python 2.4.1
installation on prairiedog, which I will now switch it to use in HEAD,
but keeping it pointed at 2.3 for 9.6 and older.
Based on some not-fun I had along the way to that, I think it would be
a good idea to do the Python version check a bit earlier than you have
here. The shlib search in PGAC_CHECK_PYTHON_EMBED_SETUP is pretty fragile
and version-dependent, which means that a person could waste a lot of time
trying to get past the "could not find shared library for Python" error
before being told that their Python is too old. I propose to move the
minimum-version check into _PGAC_CHECK_PYTHON_DIRS, say right after the
[Python configuration directory] stanza. Unless there was some specific
reason for not wanting it to happen in python.m4?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/21/17 10:18, Tom Lane wrote:
Based on some not-fun I had along the way to that, I think it would be
a good idea to do the Python version check a bit earlier than you have
here. The shlib search in PGAC_CHECK_PYTHON_EMBED_SETUP is pretty fragile
and version-dependent, which means that a person could waste a lot of time
trying to get past the "could not find shared library for Python" error
before being told that their Python is too old. I propose to move the
minimum-version check into _PGAC_CHECK_PYTHON_DIRS, say right after the
[Python configuration directory] stanza. Unless there was some specific
reason for not wanting it to happen in python.m4?
It's fine to move it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers