From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, "Brightwell, Adam" <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Yeb Havinga <yeb(dot)havinga(at)portavita(dot)nl> |
Subject: | Re: RLS Design |
Date: | 2014-09-19 16:03:45 |
Message-ID: | 20140919160345.GA13527@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-09-19 11:53:06 -0400, Robert Haas wrote:
> On Sun, Sep 14, 2014 at 11:38 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> >> On Thu, Sep 11, 2014 at 3:08 PM, Stephen Frost <sfrost(at)snowman(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2014-09-19 16:09:16 | CreateEventTrigStmt copy fix |
Previous Message | Petr Jelinek | 2014-09-19 15:58:40 | Re: Final Patch for GROUPING SETS |