Re: Re: [COMMITTERS] pgsql: Get rid of the global variable holding the error state

On 27/01/11 00:15, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On ons, 2011-01-26 at 17:47 -0500, Tom Lane wrote:
>>> I was a bit disturbed by the fact that fixing only one of the four
>>> variant files was enough to turn the whole buildfarm green. Are the
>>> other three cases even needed anymore? If so, how can we get some
>>> coverage on them?
>
>> This is explained in plpython/expected/README. As you can see there, it
>> would need some careful attention from buildfarm code and participants
>> to cover all that.
>
> Hmmm ... well, the fact that we have zero coverage on the first two
> variants definitely seems surprising and scary to me. Why aren't those
> getting hit by the non-C-locale buildfarm runs?

Looking at the README, you get the basic output file if you have server
encoding != SQL_ASCII and client encoding UTF8, which is what I was
testing with.

_0 is when you have server encoding != SQL_ASCII and client encoding !=
UTF8, which I'm not sure how popular of a setup is in the buildfarm (or
maybe by sheer luck it didn't break, dunno).

_2 is only Python 2.2, but I tried: with Python 2.2 there's a whole lot
of regression tests that fail. The last release of 2.2 is April 2003,
maybe it's time to forget about that particular dinosaur?

When coding I was running tests with Pythons 2.3 to 3.1 and trying to
keep the stuff working with these versions, as the last 2.3 release was
in March 2008.

_3 is the variant file you get if your server is SQL_ASCII and you have
a non-ancient Python, which I guess is the config quote a few buildfarm
animals has.

So three things:
* I should test with SQL_ASCII
* we might want to check if the the _0 variant file needs updates
* maybe it's time to stop supporting Python 2.2

Cheers,
Jan