Re: Proof of concept: auto updatable views [Review of Patch]

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On 8 November 2012 14:38, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>> Oh wait, that's nonsense (not enough caffeine). The rewrite code needs
>> to know whether there are INSTEAD OF triggers before it decides
>> whether it's going to substitute the base relation. The fundamental
>> problem is that the plans with and without triggers are completely
>> different, and there's no way the executor is going to notice the
>> addition of triggers if they weren't there when the query was
>> rewritten and planned.

That's a good point: if we apply the transform, then the view isn't the
plan's target table at all anymore, and so whether it has INSTEAD
triggers or not isn't going to be noticed at runtime.

> In fact doesn't the existing plan invalidation mechanism already
> protect us from this?

I'd prefer not to trust that completely, ie the behavior should be
somewhat failsafe if invalidation doesn't happen. Thinking about
that, we have these cases for the auto-updatable case as submitted:

1. INSTEAD triggers added after planning: they'll be ignored, as per
above, but the update on the base table should go through without
surprises.

2. INSTEAD triggers removed after planning: you get an error at runtime,
which seems fine.

However, for the case of only-a-conditional-INSTEAD-rule, INSTEAD
triggers added after planning will be fired. So that's not entirely
consistent, but maybe that's all right if we expect that plan
invalidation will normally prevent the case from occurring.

Basically what I'm wondering about is whether the plan should get marked
somehow to tell the executor that INSTEAD triggers are expected or not.
This doesn't seem terribly easy though, since the rewriter is doing this
well upstream of where we create a ModifyTable plan node. Maybe it's
not worth it given that invalidation should usually protect us.

regards, tom lane