Steve Howe wrote:
>
> Hello Bruce,
>
> Friday, September 6, 2002, 10:58:13 PM, you wrote:
>
> BM> Well, there was a big discussion, and I did bring up the issue in early
> BM> August to see if I could get a resolution to it and was told no
> BM> conclusion could be made.
>
> 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. And
> this would not work well with PQcmdStatus() because it returns a
> single integer entry only.
>
> This was working on some previous build, wasn't it ? What was the
> previous behavior ? Shouldn't the patch follow that way ?
In previous versions rules even fired in different orders. We cannot get
back to that, because it was the reason for total failure of rules at
all. So no, the patch should follow that way.
You say that the return should be the rows modified in the context of
the view. Er ... what is that? You mean only INSERTS, UPDATES and
DELETES made by rule actions directly to any table referenced by the
view itself count, not if a modification to another third table or view
triggers back a modification to one of these base tables in return ...
would that be through a rule or a trigger?
What about a view over views, that has rules that in turn get rewritten
by the rewrite rules of the views it consists of? What is that views
context in detail?
Jan
>
> -------------
> Best regards,
> Steve Howe mailto:howe@carcass.dhs.org
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
