Обсуждение: Reduce maintenance burden of alternative output files with \if \quit
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
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
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
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
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