Hello,
>> Would you be okay if there is one/a few effective create/drop (some tests
>> check that the create or drop fails e.g. depending on permissions, which
>> ISTM is not tested anywhere else), so that tests for various ALTER
>> DATABASE commands are combined together onto these databases?
>
> TBH, I do not see that such tests are worth adding, if they are going to
> significantly slow down the core regression tests. Those tests are run
> probably hundreds of times a day, in aggregate across all Postgres
> developers. Adding ten seconds or whatever this would add is a major
> cost, while the benefit appears trivial.
> We could consider adding expensive low-value tests like these to some
> alternate regression target that's only exercised by buildfarm members,
> perhaps. But I think there's probably a point of diminishing returns
> even in that context.
I'm not sure that the tests are "low value", because a commit that would
generate a failure on a permission check test would be a potential
security issue for Pg.
My personal experience in other contexts is that small sanity checks help
avoid blunders at a small cost. It is also worthwhile to have significant
functional tests, such as replication and so on...
As for the cost, if the proposed tests are indeed too costly, what is not
necessarily the case for what I have seen, I do not think that it would be
a great problem to have two set of tests, with one a superset of the
other, with some convention.
It is enough that these tests are run once in a while to raise an alert if
need be, especially before a release, and not necessarily on every "make
check" of every developer in the world, so that we get some value at very
low cost. So, as you suggest implicitely, maybe "make check" and "make
longcheck" or make "shortcheck" in the test infrastructure would do the
trick?
--
Fabien.
