> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> "Hiroshi Inoue" <Inoue@tpf.co.jp> 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.
Is it worse than returning "UPDATE 0" ?
Unfortunately "UPDATE 0" never means the result is unknown
but clearly means no rows were affected. It can never be safe
to return "UPDATE 0".
regards,
Hiroshi Inoue
