Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
