Re: Reduce maintenance burden of alternative output files with \if\quit - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Reduce maintenance burden of alternative output files with \if\quit
Date
Msg-id 2a8bfac6-9159-6973-f338-71bcdfad9d07@2ndquadrant.com
Whole thread Raw
In response to Re: Reduce maintenance burden of alternative output files with \if\quit  (Andres Freund <andres@anarazel.de>)
Responses Re: Reduce maintenance burden of alternative output files with \if\quit  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 05/11/2018 20:54, Andres Freund wrote:
> What mechanism are you referring to? Expected files and resultmap don't
> really fit that bill?

We can add test files on the pg_regress command line based on makefile
conditionals.

>> But some of those tests are used for testing that the unsupported
>> feature fails sanely.  For example, in the xml case, some stuff still
>> works if xml is not compiled in, and we need to check that.
> 
> Right, but a few lines would be enough for that.

I don't mind reorganizing that as long as we keep coverage, but I'm not
sure your approach will do that.

>> If it gets to complicated to maintain, then we can also split files.
>> The collation tests are split like that.
> 
>> What specific cases do you have in mind?
> 
> I find both collation and xml good cases where it'd be good not to have
> an exhaustive alternative file.  I mean, we currently don't even run the
> icu collation tests by default - and the above trick would make it
> fairly easy to automatically skip the test exactly when the database
> encoding makes that impractical?

The issue with the collation tests is different.  They need a database
with UTF8 encoding, which we cannot guarantee in the installcheck case.
Otherwise we could run them automatically with a makefile conditional.
(Early versions of the ICU patch did that, IIRC.)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Why do pg_upgrade's test use the serial schedule?
Next
From: Peter Eisentraut
Date:
Subject: Re: Support custom socket directory in pg_upgrade