> OK, what do you suggest we do?
What I'm basically suggesting is to increase the stringency of the
regression suite. Several posters supported my idea of keeping crash-
ing tests around. I think they should stick around indefinitely.
I.e. 6.4 BETA1 has some pointer errors that turn up as crashes in the
query optimizer. They seem to be of the form CLAUSE AND (CLAUSE OR
CLAUSE) or the same with the disjunction and conjunction reversed.
This sort of construct or the crashing negation construct someone
complained of earlier are likely to arise in real life. It's not
unreasonable therefore that tests for such patterns be added to the
regression suite. I.e. we collect the past queries from the real
world that crash our system with a mind to validate the software
should they recur. You mentioned that your old code somehow crept
into oid8types(), so it isn't simply a waste of testing time to
test against "old friends." Also, this defends against someone down
the road getting some "bright" idea that was discarded in the past
on grounds of workability or soundness. Fundamentally, I'm advocating
defensive coding as base practice, and I think perhaps a strong valid-
ation suite might be a step toward enforcing this. I might also advo-
cate that authors show the discipline of running a full regression
before submitting to the code base. This is mostly a cultural thing.
I think it was Jolly Chen who said that while he hadn't lost any
data, he was glad the system wasn't managing his payroll. Imagine it
IS your bank balance riding on the lines of code you write. I don't
think I'm being as draconian as some software engineering folk, but
I think these sort of steps might help PGSQL move from strength to
strength.
--
Christopher Oliver Traverse Internet
Systems Coordinator 223 Grandview Pkwy, Suite 108
oliver@traverse.net Traverse City, Michigan, 49684
"What good is a can of worms if you never open it?" -Bob Arning
