On Mon, Jun 23, 2008 at 8:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hmm ... that might be a bug, but in any case, wouldn't it be wiser to do
>
> CREATE RULE _insert AS ON INSERT TO tv DO INSTEAD
> INSERT INTO test (name) VALUES (NEW.name) RETURNING test.*;
Well, what I'm really trying to do is write a rule for inserting into
a multi-table view which has a meaningful RETURNING clause. Looking
back at the documentation for NEW, I see you are right that even if it
worked, this wouldn't do what I want. Guess I'll have to try to
figure out something else.
> Multiple evaluations of NEW in the text of a rule are a great way
> to cause yourself trouble --- consider what happens if there's
> a volatile function such as nextval() involved.
Ouch! I didn't realize that multiple references to NEW were actually
translated by the rule system into multiple *evaluations* of the
supplied arguments. Are there reasons one might desire that behavior?
I can think of simple situations in which one would *not* want such
multiple evaluation. For example, a rule on table1 which logs all
modifications of table1 to table1_log would be naturally written as
CREATE RULE log AS ON INSERT TO table1 DO ALSO
INSERT INTO table1_log (new_value,...) VALUES (NEW.value,...);
(This is very close to the example of an ON UPDATE rule given in the
manual.) But apparently if I then say
INSERT INTO table1 SET value = volatile_function();
the volatile function will be evaluated twice, and the value logged
may not be the same as the value actually inserted. This seems
counterintuitive to me; I would expect the supplied arguments to be
evaluated once and the resulting values substituted wherever NEW
appears.
Mike
