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