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 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. 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. I'm really disappointed by that. I feel I'm essentially getting punished for trying to follow what I understand to the process, which has involved me doing huge amounts of review of other people's patches and waiting a very long time to get my own stuff committed, while you bull ahead with your own patches. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
