Hello Tom,
Saturday, September 7, 2002, 5:42:33 PM, you wrote:
TL> Steve Howe <howe@carcass.dhs.org> writes:
>> BM> I suggest you read the TODO detail on the item and make a proposal on
>> BM> how it _should_ work and if you can get agreement from everyone, you may
>> BM> be able to nag someone into doing a patch.
>> I think it should return the number of rows modified in the context of
>> the view, and not exactly that of each of the tables affected.
TL> That's so vague as to be useless. What is "in the context of the view"?
TL> How does that notion help us resolve the uncertainties discussed in the
TL> TODO thread?
I just mean that PQcmdStatus() should not return a value for each
changed table but how many rows "viewable by the view" it could
change.
Again, I'm not that aware of the inners of PostgreSQL to feel
comfortable to do a better suggestion.
>> This was working on some previous build, wasn't it ? What was the
>> previous behavior ? Shouldn't the patch follow that way ?
TL> The old behavior was quite broken too, just not in a way that affected
TL> you. We will not be reverting the change that fatally broke it (namely
TL> altering the order of RULE applications for INSERTs) and so "go back
TL> to the old code" isn't a workable answer at all.
I didn't mean to revert the code but to make it work like the older
version did. I was unaware that it was broken too, but the removal now
broke the whole views/rules so I wonder what could be worst...
Also, it should have affected thousands of users, not just me. Unless
nobody uses views...
TL> I don't think fixing the code is the hard part; agreeing on what the
TL> behavior should be in complex cases is the hard part.
I understand your point and I'll try to give a proper solution but
since I'm not familiar with the PostgreSQL inners, I wonder how good
could it be...
Thanks :)
-------------
Best regards,Steve Howe mailto:howe@carcass.dhs.org
