I'm about to go off and implement this, so just to make sure we are all on the same page, here's what I think we agreed to:
In the presence of rewrite rules, the command status returned by a rewritable query will behave thusly: 1. If the original query is executed (ie, there is no unconditional INSTEAD rule), then the original query's command status is returned in all cases. Queries added by rules are ignored. 2. If the original query is suppressed by an unconditional INSTEAD rule, then return the command status of the last-executed query that is both (a) from an INSTEAD rule and (b) of the same type (SELECT, INSERT, UPDATE, DELETE) as the original query. If there is no such query, return the original query's command type and zeroes for the count and OID fields of the status. This gives us several properties that were agreed to be desirable: * Returned command type always matches original query. * Non-INSTEAD rules never affect the command status. * The user can control which query sets the command status in the INSTEAD case, by ordering the rules properly. * Reasonably compatible with the pre-7.2 behavior, taking into account that the old behavior was not predictable if you had more than one rule anyway. Note that this will force an initdb for 7.3beta3, since we need to add a field to Query nodes to keep track of whether they came from INSTEAD rules. So I will also apply the pg_cast additions that we noticed were missing a couple days ago. Were there any other items that we would have fixed for 7.3 but were holding off to 7.4 just because of wanting to avoid initdb? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly