Re: Proposal: Remove regress-python3-mangle.mk - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Proposal: Remove regress-python3-mangle.mk
Date
Msg-id 20160420022355.GA2008591@tornado.leadboat.com
Whole thread Raw
In response to Proposal: Remove regress-python3-mangle.mk  (Yury Zhuravlev <u.zhuravlev@postgrespro.ru>)
Responses Re: Proposal: Remove regress-python3-mangle.mk  (Yury Zhuravlev <u.zhuravlev@postgrespro.ru>)
Re: Proposal: Remove regress-python3-mangle.mk  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Tue, Apr 19, 2016 at 06:31:34PM +0300, Yury Zhuravlev wrote:
> Now we generate tests for plpython3 of plpython2 tests. I think we should
> write independently 2 test suite.
> Why is that bad:
> 1. Differences between python2 and python3 more than can be solved by
> regexps. And these differences are growing.

Considering we have 2756 lines of Python test SQL and just thirteen lines of
sed to mangle them, the current method is scaling nicely.

> 2. We must be careful to write tests, so as not to break the converter. And
> we can not verify the possibility python3.

I may not understand that second sentence.  We have multiple buildfarm members
verifying the python2 case and multiple members verifying the python3 case.

> 3. Because we use sed we do not tests for plpython3 under Windows. And I
> have trouble with CMake too.

Even if removing regress-python3-mangle.mk happened to be good for PL/Python,
we need build systems flexible enough to implement steps like it without a
struggle.  Our current build systems, the src/tools/msvc system and the GNU
make system, have that flexibility.  We could port regress-python3-mangle.mk
to Perl and run it on Windows; it just hasn't been a priority.

> Yes, we will have 2 times more similar code but you need to relates to the
> python2 and python3 as the different languages.

The PL/Python implementation does not view them as different languages; the
bulk of its code is the same for both python2 and python3.  We'd want almost
the same test cases in both suites.  Maintaining a single, adaptable test
suite is cheaper than forking that suite.

nm



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: pg_dump dump catalog ACLs
Next
From: Masahiko Sawada
Date:
Subject: Re: Support for N synchronous standby servers - take 2