Re: Queries using rules show no rows modified?

Michael Alan Dorman <mdorman@debian.org> writes:
> So, If I understood the proposals correctly, I think that means that
> this implementation argues for, or at least would work well with,
> Hiroshi's solution, since yours, Tom, would return a false zero in
> certain (perhaps rare) situations,

IMHO Hiroshi's solution would return false information in more cases
than mine.

The basic argument in favor of a patch like this is that if a rule
replaces (DO INSTEAD) a command with another command of the same general
type, it is useful to return the tag for the replacement command not the
original.  I agree with that.  I do not agree with the claim that we
should return a tag from the underlying implementation when a rule
rewrites a query into a form totally unrecognizable to the client.
Consider again the example of transforming an UPDATE on a view into
an INSERT on some underlying table --- but let's reverse it now and
suppose it's the other way, the client sends INSERT and the rule
replaces it with an UPDATE.  If the client is expecting to get back
"INSERT m n" and actually gets back "UPDATE n", isn't that client
likely to break?

Another issue is that the whole thing falls down if the rewriting
generates more than one query; both Hiroshi's proposal and mine will
not return any substitute tag then.  This seems rather restrictive.
Maybe we could have behavior like this: if the original command is
replaced, then use the tag from the last substituted command of the
same class (eg, if you rewrite an UPDATE into an INSERT and an UPDATE,
you get the tag from the UPDATE).  If there is *no* substitute command
of the same class, I still believe that returning "UPDATE 0" is correct
behavior.  You sent an update, zero tuples were updated, end of story.
There is not scope in this API to tell you about how many tuples might
have been inserted or deleted.

Note that as of CVS tip, the firing order of rules is predictable,
so the rule author can control which substituted command is "the last
one".  Without this I don't think that the above would work, but with
it, it seems like a moderately clean answer.  Moreover it's at least
somewhat compatible with the pre-7.2.1 behavior --- where you got the
tag from the last command *executed* regardless of any other
considerations.  That was definitely broken.
        regards, tom lane