Re: [SQL] Rules with Conditions: Bug, or Misunderstanding

Tom Lane wrote:
> Jan Wieck <janwieck@Yahoo.com> writes:
> > Tom Lane wrote:
> >> Hm.  Perhaps the "cannot update view" test is too strict --- it's not
> >> bright enough to realize that the two rules together cover all cases,
> >> so it complains that you *might* be trying to update the view.  As the
> >> code stands, you must provide an unconditional DO INSTEAD rule to
> >> implement insertion or update of a view.
>
> >     Disagree.
>
> >     A  conditional rule splits the command into two, one with the
> >     rules action and  the  condition  added,  one  which  is  the
> >     original  statement  plus the negated condition. So there are
> >     cases left where an INSERT can happen to  the  view  relation
> >     and it's the job of this test to prevent it.
>
> Well, in that case the present code is broken, because it's going to
> spit up if any part of the rewritten query shows the view as result
> relation (cf. QueryRewrite() ... note that this logic no longer looks
> much like it did the last time you touched it ;-)).  You'd have to
> convert the existing rewrite-time test into a runtime test in order to
> see whether the query actually tries to insert any tuples into the view.
   Yepp.

> While that is maybe reasonable for insertions, it's totally silly
> for update and delete queries.  Since the view itself can never contain
> any tuples to be updated or deleted, a runtime test that errors out
> when one attempts to update or delete such a tuple could never fire.
> I don't think that means that we shouldn't complain about an update
> or delete on a view.
>
> I think the test is best left as-is...
   Since  conditional  rules  aren't  any  better compared to an   unconditional multi-action  instead  rule  where
the single   actions  have all the different conditions, let's leave it as   is and insist on one unconditional instead
rule.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #