Tom Lane wrote:
> 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
> executed query 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.
I am confused how yours differs from mine. I don't see how the last
matching tagged query would not be from an INSTEAD rule. Are you
thinking multiple queries in the query string?
> 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...
Seems we are adding up reasons for initdb. :-)
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
