On 2 July 2012 21:34, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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. >
Yeah, I think you're right - the default ACLs will typically give sensible behaviour. So unless users have been cavalier with the use of GRANT ALL, their existing views are only going to start becoming updatable to the owners of the views (and only then if the view owner already has write permission on the underlying table). Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
