Robert Haas <robertmh...@gmail.com> writes: > On Sun, Jul 1, 2012 at 6:35 PM, Dean Rasheed <dean.a.rash...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers