On Saturday 13 June 2009 22:01:43 Robert Haas wrote:
> > I recommend, however, that you think about writing a regression test for
> > this, so the interfaces are explicit, and those tweaking them in the
> > future know what they are dealing with.
>
> I would like to have something in this area, but Tom didn't think it
> was workable.
>
> http://archives.postgresql.org/message-id/603c8f070904151623ne07d744k615edd
>4aa669a64a@mail.gmail.com
>
> Currently, we don't even have something trivial like "EXPLAIN SELECT
> 1" in the regression tests, so even if you completely break EXPLAIN so
> that it core dumps (voice of experience speaking here) make check
> still passes with flying colors.
That post described a scenario where you check whether given a data set and
ANALYZE, the optimizer produces a certain plan. I agree that that might be
tricky.
A regression test for EXPLAIN, however, should primarily check whether the
output format is stable. We are planning to offer this as a public interface,
after all. You could use faked up statistics and all but one or two plan
types turned off, and then the results should be pretty stable. Unless the
fundamental cost model changes, but it doesn't do that very often for the
simpler plan types anyway. Things to check for would be checking whether all
the fields are there, quoted and escaped correctly, and what happens if
statistics are missing or corrupted, etc. Or whether you get any output at
all, as you say.
