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

[ finally getting back to this patch, after many distractions ]

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On 8 November 2012 21:13, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think the most reasonable backwards-compatibility argument is that we
>> shouldn't change the behavior if there are either INSTEAD rules or
>> INSTEAD triggers. Otherwise we may be disturbing carefully constructed
>> behavior (and no, I don't buy that "throw an error" couldn't be what the
>> user intended).

> The current behaviour, if there is only a conditional instead rule, is
> to throw an error whether or not that condition is satisfied. It's
> hard to imagine that's an error the user intended.

Well, the current definition is that a rule set with a conditional
DO INSTEAD rule is incomplete and needs to be fixed. I don't see
anything particularly wrong with that, and I remain hesitant to silently
redefine the behavior of existing rule sets.

> However, given the niche nature of conditional instead rules, it
> doesn't seem so bad to say that auto-updatable views don't support
> them at the moment, so long as backwards compatibility is maintained
> in the table and trigger-updatable view cases. So I think the current
> behaviour to maintain is, for a relation with only a conditional
> instead rule:

> if the relation is a table:
> if the condition is satisfied: fire the rule action
> else: modify the table
> else if the relation is a view with triggers:
> if the condition is satisfied: fire the rule action
> else: modify the view using the triggers
> else:
> throw an error unconditionally

> That's backwards compatible and easy to document - views with
> conditional instead rules are not auto-updatable. If anyone cared
> enough about it, or could come up with a realistic use case, we could
> always add support for that case in the future.

But if there's an unconditional INSTEAD rule, we aren't going to apply
the transformation either, so it seems to me this comes out to the
same thing I said above: any kind of INSTEAD rule disables application
of the auto-update transformation.

regards, tom lane