Re: RLS Design

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: RLS Design
Дата
Msg-id 20140919160345.GA13527@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: RLS Design  (Robert Haas <robertmhaas@gmail.com>)
Список 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@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 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: Final Patch for GROUPING SETS
Следующее
От: Petr Jelinek
Дата:
Сообщение: CreateEventTrigStmt copy fix