Hello Tom,
> psql_if_on_error_stop ... ok (test process exited with exit code 3)
>
> Don't think we can have that. Even if pg_regress considers it a success,
> every hacker is going to have to learn that that's a "pass",
Well, it says "ok"...
> and I don't think I want to be answering that question every week till
> kingdom come.
Hmmm.
What if the test is renamed, say "psql_if_exit_code_3"? Maybe the clue
would be clear enough to avoid questions? Or just remove the exit message
but check the exit code is as expected?
> I'm not really sure we need a test for this behavior.
My 0.02€:
I have learned the hard way over the years that what is not tested does
not really work, including error behaviors. These tests (well, the initial
TAP version at least) helped debug the feature, and would help keeping it
alive when the code is updated.
Now if you do not want this test, it can be removed. The feature is worthy
even without it.
> If we're sufficiently dead set on it, we could go back to the TAP-based
> approach,
Hmmm. You rejected it. I agree that TAP tests are not well suited for some
simple tests because of their initdb overhead.
> but I still doubt that this test is worth the amount of overhead that
> would add.
I think that there is an underlying issue with keeping on rejecting tests
which aim at having a reasonable code coverage of features by exercising
different paths.
Maybe there could be some "larger but still reasonable tests" activated on
demand so as to being able to keep tests and run them from time to time,
which would not interfere too much with committers' work, and that some
farm animals would run?
I thought that was one of the purpose of TAP tests, but obviously it is
not.
--
Fabien.