"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> If you'd not like to change the behavior, I would change it, OK ?
>>
>> To what? I don't want to simply undo the 7.2 change.
> What I'm thinking is the following makeshift fix.
> I expect it solves Ron's case though I'm not sure.
> Returning UPDATE 0 seem to make no one happy.
Agreed, that doesn't seem like it's going over well. Let's see, you
propose returning the tag if there is only one replacement query, ie,
we had just one DO INSTEAD rule. [ thinks... ] I guess the only thing
that bothers me about this is the prospect that the returned tag is
completely different from what the client expects. For example,
consider a rule like ON UPDATE DO INSTEAD INSERT INTO history_table...
With your patch, this would return an "INSERT nnn nnn" tag, which'd
confuse a client that expects an "UPDATE nnn" response. (This is one
of the issues that prompted changing the behavior to begin with.)
Would it be reasonable to allow the rewritten query to return a tag
only if (a) it's the only query, per your patch AND (b) it's the same
query type as the original, unrewritten query?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
