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
