> -----Original Message-----
> From: Rod Taylor [mailto:rbt@rbt.ca] 
> Sent: Monday, September 09, 2002 10:55 AM
> To: Steve Howe
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Rule updates and PQcmdstatus() issue
> 
> 
> > existed, had a brief discussion on the subject, and 
> couldn't reach an 
> > agreement. That's ok for me, I understand... but releasing versions 
> > known to be broken is something I can't understand.
>  -9' the postmaster
> 
> If we didn't do that, then Postgresql never would have been 
> released in the first place, nor any date between then and now.
> 
> There has been, and currently is a ton of known broken, 
> wonky, or incomplete stuff -- but it's felt that the current 
> version has a lot more to offer than the previous version, so 
> it's being released.
> 
> This works for *all* software.  If you never release, nothing 
> gets better.
> 
> 
> 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.

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.

Now, at first blush, the open source strategy seems ludicrous.  After
all, who will want to use a product which could potentially (albeit
unlikely) destroy your data or give wrong results?  Then, after a bit of
thought, you can see that the same sort of strategy as the open source
projects *is* followed by one very large and very successful software
giant.  So maybe "burgeoning featuritis without extreme concern for
robust stability" isn't such a stupid strategy after all. ;-)

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.

Mon, 9 Sep 2002 11:30:52 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: Rule updates and PQcmdstatus() issue
On Mon, Sep 09, 2002 at 11:30:52AM -0700, Dann Corbit wrote:
> 
> 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.

But in fairness, I think you'd be hard pressed to find a set of
developers anywhere who take more seriously that the PostgreSQL core
the responsibility to provide stable, correct software.  I've
reported show-stopping bugs to commercial database providers and on
the PostgreSQL lists, and I'd be hard pressed to come up with an
occasion where I received from a commercial software company service
that was even 1/10th the quality and speed that I get here.  

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Mon, 9 Sep 2002 15:22:50 -0400
Andrew Sullivan <andrew@libertyrms.info>
Re: Rule updates and PQcmdstatus() issue
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

Mon, 9 Sep 2002 14:25:48 -0500
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: Rule updates and PQcmdstatus() issue
> > If we didn't do that, then Postgresql never would have been 
> > released in the first place, nor any date between then and now.

> 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

Most companies / groups (opensource or otherwise) will not hold back
many bugfixes and features for the sake of getting an additional out of
the way fix in as it tends to piss off the majority of the users.

I'm afraid right now I see this as a very minor item which is heavily
broken, meaning it's really really important to very few users.

Not having foreign keys break when renaming a column or table will
probably affect more people and is awaiting the next release.  Ditto for
security enhancements.  I see these as more important -- since they
affect me :)

If the changes are agreed upon and fixed, great.  It's a better product
because of it.  But forcing others to use an older version with
equivelently broken items because the next one doesn't do everything
perfectly doesn't make for progress.

However, rest assured, with anything if you push and put in the work
require it'll eventually go where you want it to.

-- 
  Rod Taylor


09 Sep 2002 15:41:59 -0400
Rod Taylor <rbt@rbt.ca>
Re: Rule updates and PQcmdstatus() issue
On Mon, 2002-09-09 at 21:25, Ross J. Reedstrom wrote:
> 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).

Why is "rules firing in an unpredicatable order" a bug but "returned
affected tuple count is wrong " just a compatibility issue ?

Afaik, rule firing order has never been promised, while pqCmdTuples()
has.

> 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.

One approach could be to expose the tuple count at SQL level and then
let the user decide what to return.

> 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.

You usually learn afterwards when it has been "too long" ;)

--------------
Hannu


10 Sep 2002 10:39:18 +0200
Hannu Krosing <hannu@tm.ee>
Re: Rule updates and PQcmdstatus() issue
Hannu Krosing <hannu@tm.ee> writes:
> Why is "rules firing in an unpredicatable order" a bug but "returned
> affected tuple count is wrong " just a compatibility issue ?
> Afaik, rule firing order has never been promised, while pqCmdTuples()
> has.

There has never been any spec saying exactly what PQcmdTuples would give
in complicated cases.  The effective behavior pre-7.2 was that you'd get
the result tag of the last action executed, but this was undocumented,
and unsafe to rely on in multi-rule cases even then, considering that
the firing order of rules was not predictable.

What actually happened was this: in 7.2 we changed ON INSERT rule firing
to execute non-INSTEAD rules after the original INSERT, rather than
before it.  In the old behavior, non-INSTEAD rules just plain did not
work with an INSERT: they wouldn't see any "NEW" row, because it wasn't
there yet when they ran.  This is surely a bug fix in my book (and it is
unrelated to the 7.3 change that provides predictable firing order of
multiple rules).

Now the side effect of that change was to change PQcmdTuples' behavior,
because the "last action" was no longer the same thing as before.  This
broke various clients that were depending on the "last action" to be the
original INSERT.  The fix we applied was to redefine PQcmdTuples to
return the result count of the original query regardless of firing
order.

This behavior is evidently not good for Steve, and I'm perfectly
prepared to discuss modifying it some more --- but I don't want to have
a PQcmdTuples behavior-of-the-month with new changes in every release.
I want a discussed, agreed-to, well-defined behavior that we aren't
going to revisit again in future releases.  When we have that agreement
we can implement it and forget it ... but if we apply a bandaid now
and then change the behavior again later, we're just going to make life
even harder for clients.  I'd rather leave the behavior broken (by
Steve's view anyway) but *the same as 7.2* than have a new but still-
unsatisfactory definition in there for 7.3.

I think the other developers have the same negative opinion about API
churn as I do, and so when we couldn't get agreement about what to
do back in May, we shelved the topic in hopes a fresh idea would come
along.

Now could we drop the name-calling and the bogus opinionating about
how serious or not-serious this problem is, and concentrate on finding
a satisfactory answer?

			regards, tom lane

Tue, 10 Sep 2002 10:46:37 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Rule updates and PQcmdstatus() issue 