On Sun, Sep 14, 2014 at 11:38 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost <sfrost@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