Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]

> But what we're
> really proposing is better documentation of known bugs, and the
> construction of a test suite that will not only check basic
> functionality, but everything anyone can think of that could be
> considered sort of normal usage, and we certainly all have different
> ideas about what is "normal."
> This, no matter what changes are made, we know where we stand.  That's
> all that has been said.

And that is exactly what a regression test is for.

I think the issues here are what the proper response to a _new_ problem
report should be, and how that new problem should be documented if it is
not going to be fixed right away.

I should mention that Jose' De Silva, who is somehow connected with this
thread since his address shows up in the subject line, did a great job
of writing reference documentation which will appear in the next
Postgres release. He included several examples of deficient Postgres
features, and as I transcribed that documentation was able to fix
several of them. He went to the trouble to write it down, and that
resulted in fixes.

We shouldn't blow this problem out of proportion; although in hindsight
a query as simple as "select not b from t" should be an obvious one, it
has not been reported as a problem in the entire history of Postgres.
That's either because no one had ever tried it, or they did but didn't
bother reporting it (imho letting all of us down in the process). So
there is no way to have guessed that it should have been in the current
regression test. If it had been, it would have never been broken, which
is sort of circular but true...

Now that it's been reported, it will likely be fixed (though don't get
the wrong impression; this long thread has actually gotten in the way of
that rather than helped :). This thread is helpful though because it may
result in a better way of tracking features and problems. What you see
with the Postgres product is what is possible with the current set of
active developers and maintainers. We are _always_ open to others
contributing, but we can't just say "Oh, sure we'll do that" since we
are already putting in as much time as our real lives allow.

There are several people who have expressed interest in this, and Bruce
and I have been responding as best we can, but we don't mean to stifle
innovation or good ideas. I've tried to help the discussion by moving it
away from "regression test", which has a specific goal, to some "bad
features test" or "bad features list" which would document the things
that don't work right. It would be helpful if folks are interested in
maintaining it, and not so helpful if they aren't.

Cheers.

                      - Tom