Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Of cource it is nice to have a complete solution > immediately but it doesn't seem easy. My patch is > only a makeshift solution but fixes the most > siginificant case(typical updatable views).
I would like to devise a complete solution *before* we consider installing makeshift solutions (which will institutionalize wrong behavior). There seems to be some feeling here that in the presence of rewrites you only want to know that "something happened". Are you suggesting that the returned tuple count should be the sum of all counts from insert, update, and delete actions that happened as a result of the query? We could certainly implement that, but it does not seem like a good idea to me. I'm also concerned about having an understandable definition for the OID returned for an INSERT query --- if there are additional INSERTs triggered by rules, does that mean you don't get to see the OID assigned to the single row you tried to insert? You'll definitely get push-back if you propose that. But if we add up all the actions for the generated queries, we are quite likely to be returning an OID along with an insert count greater than one --- which is certainly confusing, as well as contrary to the existing documentation about how it works. Let's please quit worrying about "can we install a hack today" and instead try to figure out what a sensible behavior is. I don't think it's likely to be hard to implement anything we might come up with, considering how tiny this API is. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html