Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jul 1, 2012 at 6:35 PM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>> Basically what it does is this: in the first stage of query rewriting,
>> just after any non-SELECT rules are applied, the new code kicks in -
>> if the target relation is a view, and there were no unqualified
>> INSTEAD rules, and there are no INSTEAD OF triggers, it tests if ...
>> The consensus last time seemed to be that backwards compatibility
>> should be offered through a new GUC variable to allow this feature to
>> be disabled globally, which I've not implemented yet.
> I think the backward-compatibility concerns with this approach would
> be much less than with the previously-proposed approach, so I'm not
> 100% sure we need a backward compatibility knob.
If the above description is correct, the behavior is changed only in
cases that previously threw errors, so I tend to agree that no
"backwards compatibility knob" is needed.
regards, tom lane
