On 2018-11-05 15:08:33 +0100, Peter Eisentraut wrote: > On 03/11/2018 22:55, Andres Freund wrote: > > We have a few alterntive expected output files that are essentially full > > of errors, because a certain feature isn't supported. Those are somewhat > > painful to maintain. I wonder if it'd be a good idea to reduce the > > maintenance overhead for some of them by putting something like > > > > SELECT NOT feature_check_expr() AS dont_have_feature > > \gset > > \if :dont_have_feature > > \quit > > \endif > > > > at the start of such regression tests. Then the alternative > > 'dont-have-the-feature' output file will stay the same when adding new > > tests. > > If we don't want to run the file at all under a certain condition, we > have ways to do that, and we don't need those above mechanism.
What mechanism are you referring to? Expected files and resultmap don't really fit that bill? > 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. > 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? Greetings, Andres Freund