Re: Reduce maintenance burden of alternative output files with \if \quit

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reduce maintenance burden of alternative output files with \if \quit
Date: 2018-11-05 19:54:07
Message-ID: 20181105195407.2kd7ikpfrjjwluqy@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-11-05 20:01:58 Re: settings to control SSL/TLS protocol version
Previous Message Tom Lane 2018-11-05 19:42:18 Re: How to properly use the Executor interface?