Hiroshi Inoue <Inoue@tpf.co.jp> 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
