Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 30. August 2006 18:01 schrieb Tom Lane:
>> This is the first time I've actually looked at this patch, and I am
>> dismayed. viewUpdate.c looks like nothing so much as a large program
>> with a small program struggling to get out.
> But later SQL versions allow some of that, so at least it shouldn't hurt to
> have some parts of the code to be more general in preparation of that.
If it bloats the code to unreadability, it's bad.
>> I'm unclear as to why you've got DO INSTEAD NOTHING rules in there ---
> You need to have one unconditional rule if you have a bunch of conditional
> ones. The system does not see through the fact that the conditional ones
> cover all cases.
AFAICS, for the cases we are able to implement within the existing rule
mechanism, there should be exactly one unconditional rule. If you
propose more, then you are going to have insurmountable problems with
the usual sorts of multiple-evaluation risks.
The proposed WITH CHECK OPTION implementation is unworkable for exactly
this reason --- it will give the wrong answers in the presence of
volatile functions such as nextval(). I believe that we cannot
implement WITH CHECK OPTION as a rule. It's a constraint, instead,
and will have to be checked the way the executor presently checks
constraints, ie after forming the finished new tuple(s).
(Someday we're going to have to look into redesigning the rule system
so that it can cope better with the kinds of situations that give rise
to multiple-evaluation problems. But today is not that day.)
It's possible that if we strip the patch down to SQL92-equivalent
functionality (no multiple base rels) without WITH CHECK OPTION,
we would have something that would work reliably atop the existing
rule mechanism. It's getting mighty late in the 8.2 cycle to be
doing major rework though.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
