On 7 November 2012 22:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dean Rasheed <dean.a.rasheed@gmail.com> writes:
>> Thanks for looking at this.
>> Attached is a rebased patch using new OIDs.
>
> I'm starting to look at this patch now. I don't understand the intended
> interaction with qualified INSTEAD rules. The code looks like
>
> + if (!instead && rt_entry_relation->rd_rel->relkind == RELKIND_VIEW)
> + {
> + Query *query = qual_product ? qual_product : parsetree;
> + Query *newquery = rewriteTargetView(query, rt_entry_relation);
>
> which has the effect that if there's a qualified INSTEAD rule, we'll
> apply the substitution transformation to the
> modified-by-addition-of-negated-qual query (ie, qual_product).
Yes that's what I was aiming for. I thought that if the rule's
qualifier isn't satisfied and the rule isn't fired, it should attempt
to go ahead with the view update. This might result in an INSTEAD OF
trigger firing, substitution of the base relation, or an error being
raised.
> This seems to me to be dangerous and unintuitive, not to mention
> underdocumented. I think it would be better to just not do anything if
> there is any INSTEAD rule, period. (I don't see any problem with DO
> ALSO rules, though, since they don't affect the behavior of the original
> query.)
>
Is this any more dangerous than what already happens with qualified rules?
If we did nothing here then it would go on to either fire any INSTEAD
OF triggers or raise an error if there aren't any. The problem with
that is that it makes trigger-updatable views and auto-updatable views
inconsistent in their behaviour with qualified INSTEAD rules. I don't
think the existing interaction between trigger-updatable views and
qualified INSTEAD rules is documented, so perhaps that's something
that needs work.
Regards,
Dean