Re: improving python3 regression test setup - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: improving python3 regression test setup
Date
Msg-id 504A3751.8050704@gmx.net
Whole thread Raw
In response to Re: improving python3 regression test setup  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 9/6/12 8:56 PM, Alvaro Herrera wrote:
> Excerpts from Peter Eisentraut's message of jue sep 06 21:33:33 -0300 2012:
>> I have developed a patch to make the python3 regression test setup a bit
>> simpler.  Currently, we are making mangled copies of
>> plpython/{expected,sql} to plpython/python3/{expected,sql}, and run the
>> tests in plpython/python3.  This has the disadvantage that the
>> regression.diffs file, if any, ends up in plpython/python3, which is not
>> the normal location.  If we instead make the mangled copies in
>> plpython/{expected,sql}/python3/, we can run the tests from the normal
>> directory, regression.diffs ends up the normal place, and the pg_regress
>> invocation also becomes a lot simpler.  It's also more obvious at run
>> time what's going on, because the tests end up being named
>> "python3/something" in the test output.
> 
> Uhm .. wouldn't it be simpler if the sql files were in input/ and the
> expected in output/, and have pg_regress do the mangling?  Maybe there
> would need to be some tweak to pg_regress itself (such as the ability to
> pass mangling to be done), but that seems cleaner to me.

Maybe that could be made to work if pg_regress were passed in a script
to do the mangling.  (You don't want to hard-code the specific
requirements of plpython into pg_regress.)  But that seems like a lot of
extra work for no real additional benefit.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Next
From: Pavan Deolasee
Date:
Subject: Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump