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
