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

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

From

Andres Freund

Date:

03 November 2018, 21:55:15

Hi,

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.

It's a bit annoying that when running such a sequence interactively one
can hit
    if (pset.cur_cmd_interactive && !active_branch &&
        !is_branching_command(cmd))
    {
        psql_error("\\%s command ignored; use \\endif or Ctrl-C to exit current \\if block\n",
                   cmd);
    }
but given that's just when running interactively, it shouldn't be too
bad.

Greetings,

Andres Freund

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

From

Peter Eisentraut

Date:

05 November 2018, 14:08:33

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.  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.  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?

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

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

From

Andres Freund

Date:

05 November 2018, 19:54:07

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

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

From

Peter Eisentraut

Date:

07 November 2018, 07:21:09

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

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

From

Andres Freund

Date:

07 November 2018, 07:24:08

Hi,

On 2018-11-07 08:21:09 +0100, Peter Eisentraut wrote:
> 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 we don't...


> >> 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.)

But isn't that precisely addressable with my proposed approach? I'll
send a patch.

Greetings,

Andres Freund