Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.
>>
>> You could have both INSTEAD and non-INSTEAD rules firing for the same
>> original query. If the alphabetically-last rule is a non-INSTEAD rule,
>> then there's a difference.
> How do we get multiple rules on a query? I thought it was mostly
> INSERT/UPDATE/DELETE, and those all operate on a single table.
You can create as many rules as you want. One reasonably likely
scenario is that you have a view, you make an ON INSERT DO INSTEAD
rule to support insertions into the view (by inserting into some
underlying table(s) instead), and then you add some not-INSTEAD
rules to perform logging into other tables that aren't part of the
view but just keep track of activity.
You'd not want the logging activity to usurp the count result for this
setup, I think, even if it happened last. (Indeed, that might be
*necessary*, if for some reason it needed to access the rows inserted
into the view's base table.)
This approach would give us a general principle that applies in all
cases: not-INSTEAD rules don't affect the returned command result.
Perhaps that would answer Manfred's thought that we should be able
to label which rules affect the result. If you have any INSTEAD rules,
then it doesn't matter exactly how many you have, so you can mark them
INSTEAD or not to suit your fancy.
regards, tom lane