On 2014-09-19 11:53:06 -0400, Robert Haas wrote: > On Sun, Sep 14, 2014 at 11:38 AM, Stephen Frost <sfr...@snowman.net> wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost <sfr...@snowman.net> wrote: > >> > If we want to be able to disable RLS w/o dropping the policies, then I > >> > think we have to completely de-couple the two and users would then have > >> > both add policies AND turn on RLS to have RLS actually be enabled for a > >> > given table. I'm on the fence about that. > >> > > >> > Thoughts? > >> > >> A strong +1 for doing just that. > > > > Alright, updated patch attached which does just that (thanks to Adam > > for the updates for this and testing pg_dump- I just reviewed it and > > added some documentation updates and other minor improvements), and > > rebased to master. Also removed the catversion bump, so it should apply > > cleanly for people, for a while anyway. > > I specifically asked you to hold off on committing this until there > was adequate opportunity for review, and explained my reasoning. You > committed it anyway.
I was also rather surprised by the push. I wanted to write something about it, but: > This patch, on the other hand, was massively revised after the start > of the CommitFest after many months of inactivity and committed with > no thorough review by anyone who was truly independent of the > development effort. It was then committed with no warning over a > specific request, from another committer, that more time be allowed > for review. says it better. I think that's generally the case, but doubly so with sensitive stuff like this. > I wonder if I am equally free to commit my own patches without > properly observing the CommitFest process, because it would be a whole > lot faster. My pg_background patches have been pending since before > the start of the August CommitFest and I accepted that I would have to > wait an extra two months to commit those because of a *clerical > error*, namely my failure to actually add them to the CommitFest. FWIW, I think if a patch has been sent in time and has gotten a decent amount of review *and* agreement it's fair for a committer to push forward. That doesn't apply to this thread, but sometimes does for others. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers