Python 3.x versus PG 9.1 branch
In view of our rather embarrassing failure to cover the back branches
with Python 3.5-related regression test adjustments, I think there is
a clear need for a buildfarm critter that's testing with Python 3.5,
and I've been working on setting one up. It's passing at the moment
for 9.2 and up, but not for 9.1, because we've repeatedly not bothered
to back-port regression test fixes for newer Pythons into that branch.
I could just omit Python 3 coverage for that branch in the critter's
configuration, but I wonder exactly why things are that way.
For clarity, to cover 9.1 I think we'd need to back-patch some subset
of these commits:
f16d52269 ff2faeec5 d0765d50f 6bff0e7d9 527ea6684 8182ffde5
45d1f1e02 2cfb1c6f7
The precedent of not fixing 9.1 started with the last of these.
I haven't looked into the details of which changes would actually
apply to 9.1, I just searched for commits that touched the Python
regression tests. We'd really only need enough changes to address
the regression failures I'm getting, which are attached below.
Or we could just blow it off on the grounds that 9.1 is not long
for this world anyhow.
Opinions anyone?
regards, tom lane
Attachments:
plpy91.diffstext/x-diff; charset=us-ascii; name=plpy91.diffsDownload+42-42
On Wed, Jan 13, 2016 at 11:46:07AM -0500, Tom Lane wrote:
[...] we've repeatedly not bothered
to back-port regression test fixes for newer Pythons into that branch.
I could just omit Python 3 coverage for that branch in the critter's
configuration, but I wonder exactly why things are that way.For clarity, to cover 9.1 I think we'd need to back-patch some subset
of these commits:f16d52269 ff2faeec5 d0765d50f 6bff0e7d9 527ea6684 8182ffde5
45d1f1e02 2cfb1c6f7The precedent of not fixing 9.1 started with the last of these.
Or we could just blow it off on the grounds that 9.1 is not long
for this world anyhow.Opinions anyone?
I respect the 2012-era decision to have 9.1 not support newer Python, and I
think the lack of user complaints validates it. I wouldn't object to
overturning the decision, either. The biggest risk, albeit still a small
risk, is that newer Python is incompatible with 9.1 in a way that the test
suite does not catch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 14, 2016 at 12:37 PM, Noah Misch <noah@leadboat.com> wrote:
On Wed, Jan 13, 2016 at 11:46:07AM -0500, Tom Lane wrote:
[...] we've repeatedly not bothered
to back-port regression test fixes for newer Pythons into that branch.
I could just omit Python 3 coverage for that branch in the critter's
configuration, but I wonder exactly why things are that way.For clarity, to cover 9.1 I think we'd need to back-patch some subset
of these commits:f16d52269 ff2faeec5 d0765d50f 6bff0e7d9 527ea6684 8182ffde5
45d1f1e02 2cfb1c6f7The precedent of not fixing 9.1 started with the last of these.
Or we could just blow it off on the grounds that 9.1 is not long
for this world anyhow.Opinions anyone?
I respect the 2012-era decision to have 9.1 not support newer Python, and I
think the lack of user complaints validates it. I wouldn't object to
overturning the decision, either. The biggest risk, albeit still a small
risk, is that newer Python is incompatible with 9.1 in a way that the test
suite does not catch.
The lack of user complaints regarding 9.1 using Python 3.5 and the
fact that 9.1 will be EOL in 8~9 months does not sound worth it to me.
A couple of days ago I bumped into this article, leading to the
thought that Python 4.0 may induce as much breakage as 3.5 did :(
http://astrofrog.github.io/blog/2016/01/12/stop-writing-python-4-incompatible-code/
Just something to keep in mind.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 13, 2016 at 11:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Or we could just blow it off on the grounds that 9.1 is not long
for this world anyhow.
+1 for blowing it off. I can't see the point in putting effort into
this. Nobody should be spinning up new PostgreSQL 9.1 deployments at
this point, and whatever PostgreSQL 9.1 deployments already exist are
evidently OK with what we've been doing up until now. So it seems
unlikely to help anyone.
Also, if it does help someone, it will be helping them to deploy a
nearly-obsolete PostgreSQL version at a time when, really, it would be
much better if they were thinking about how to get off that version.
Moreover, it's not inconceivable that back-porting all of those
commits could break something that works now, in which event we would
end up worse off than we are today.
So I really don't see any upside.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers