Tom Lane wrote: > 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.
Oh, I like that, and rules fire alphabetically, right? -- 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
