> -----Original Message----- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > > "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.
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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
