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 >4aa669a...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
