On Fri, 2002-05-10 at 06:27, Tom Lane wrote:
> 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?
At least when there was actually no insert you don't
and if there actually was more than 1 insert then INSERT 0 N seems quite
reasonable to me.
It may even be that returning a concatenation of results would be
acceptable for current libs
INSERT OID 1 INSERT 0 3 UPDATE 2 DELETE 2
> 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.
The problem seems to be that recent changes broke updatable views for a
few users. So have these basic options:
1. revert the changes until we have a consensus on doing the right thing (seems best to me)
2. change clients (client libraries) for 7.2 cycle at least
3. not revert but install a hack today so that it seems like things still work ;)
4. figure out correct behaviour and do that for 7.2.2
5. do nothing and tell users to keep themselves busy with other things until there is consensus about new behaviour.
option 5 seems to be worst, as it leaves users in a state with no clear
view of what is going to happen - we have just changed one arguably
broken behaviour for a new one and are probably going to change it again
soon when we figure out what the right behaviour should be.
> I don't think
> it's likely to be hard to implement anything we might come up with,
> considering how tiny this API is.
The sensible behaviour for updatable views would be to report ho many
rows visible through this view were changed, but this can be hard to do
in a generic way.
-----------------
Hannu
