Bruce Momjian <pgman@candle.pha.pa.us> writes:
> We have talked about possible return values for RULES, particularly
> INSTEAD rule. Manfred has a nice example here, so I propose we handle
> INSTEAD rules this way: that we return the oid and tuple count of the
> last INSTEAD rule query with a tag matching the main query.
Hmm ... that's subtly different from what I'd seen discussed before.
I thought the idea was
1. If no INSTEAD rule: return tag, count, and OID of original query, regardless of what is added by non-INSTEAD
rules. (I think this part is not controversial.)2. If any INSTEAD rule: return tag, count, and OID of the last
executedquery that has the same tag as the original query. If no substituted query matches the original query's tag,
return original query's tag with zero count and OID. (This is where the going gets tough.)
I think you just modified the second part of that to restrict it to
queries that were added by INSTEAD rules. This is doable but it's
not a trivial change --- in particular, I think it implies adding
another field to Query data structure so we can mark INSTEAD-added
vs non-INSTEAD-added queries. Which means an initdb because it breaks
stored rules.
Offhand I think this might be worth doing, because I like that subtle
change in behavior. But we should understand exactly what we're doing
here...
regards, tom lane