Re: The rule question before, request official documentation on the problem

Hmm.....

I just came up with a far more problematic case too and wonder if
documentation is enough. Maybe we should warn about potential problems
more loudly.

Imagine the following case: insert into test_table (test) values
(random()) where an insert rule propagates the changes faithfully to the
next table. In short, all we are doing is inserting random numbers into
different tables and generating them on each insert. In short, rules
provide no guarantee of predictable behavior because queries can always
mess with them.

Let me put that a different way: rules can *only* be used where data
integrity is not at stake. My own thinking is that it might be time to
make an official recommendation that they are only safe for views.

Best Wishes,
Chris Travers

Stuart Cooper wrote:
>> My request at this point is to officially and clearly document this as a
>> substantial limitation of rules. It is not obvious that this is how
>> rules are supposed to behave in this case, and even assuming that the
>> current behavior is desired, it would be nice to let us know this :-)
>
> It's documented.
>
> Section 35.3.1 of Postgresql 8.2 PDF docmentation, 2nd last paragraph:
>
> ***
> For any reference to NEW, the target list of the original query is
> searched
> for a corresponding entry. If found, that entry's expression replaces the
> reference.
> ***
>
> "expression" is the key term here. NEW.id is an expression, *not* a
> value.
>
> Cheers,
> Stuart.
>
>