Re: Rule updates and PQcmdstatus() issue - Mailing list pgsql-hackers

On Mon, Sep 09, 2002 at 11:30:52AM -0700, Dann Corbit wrote:
> > 
> > I suspect it'll be several more major releases before we 
> > begin to consider it approaching completely functional.
> 
> I believe that the surprise is at the focus, when it comes to a release.
> With commercial products (anyway) if you have any sort of show-stopper
> bug (crashing, incorrect results, etc.) you do not release the tool
> until the bug, and all others like it, are fixed.  Bugs that have to do
> with appearance or convenience can be overlooked for a release as long
> as they are documented in the release notes.  Now, it is not unlikely
> that there are unintentional show-stopper bugs that get through Q/A.
> But intentionally passing them through would be incompetent for a
> commercial enterprise.

Hmm, you don't have any drinking buddies who work QA, do you? _Lots_ of
known, "eat your harddrive" bugs get classified as "to be fixed in future
release" in commercial software, when the release date pressure grows.

> With open source projects, the empasis tends to be on features, with far
> less regard for correcting known problems.  Even bugs that can cause a
> crash seem to be viewed as acceptable if they happen rarely.

Huh? I tend to see exactly the opposite. Actual crash and "wrong
answer" bugs tend to get very prompt attention on all the open source
projects I know and use. What _does_ get delayed or even ignored are "bug
compability" problems, like this one. That is, software that relies on the
"affected rows" count is in fact broken, since it's making assumptions
about that number that were never promised in any standard or interface
docs.

<snip silly comparison to commercial software house>

> All kidding aside, I would like to see increased emphasis on stability
> and correctness.  But I will admit that it is a lot less fun than adding
> new features.

And this has got to be trolling: PostgreSQL is one of the _most_
stability and correctness focused software projects I've ever known. In
this particular case, the complaints about this issue where "Your bugfix
broke my tool! make it better!" The answer was "We can't just put it
back, that's an actual bug in there (rules firing in an unpredicatable
order). What's the _correct_ behavior?" The people with the complaints
then did not come up with a compelling, complete description of what
the correct behavior should be. There's always been vague parts to the
"desired behavior" like the phrase Tom pointed out: "in the context of
the view" which was clarified to mean "viewable by the view", which is
nearly impossible to code, if not an example of the halting problem.

PostgreSQL as a project errs on the side of not coding the quick fix,
in favor of waiting for the right answer. Sometimes too long, but this
case isn't one of those, IMHO.

Ross
-- 
Ross Reedstrom, Ph.D.                                 reedstrm@rice.edu
Executive Director                                  phone: 713-348-6166
Gulf Coast Consortium for Bioinformatics              fax: 713-348-6182
Rice University MS-39
Houston, TX 77005