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