Re: Rethinking the parameter access hooks for plpgsql's benefit - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Rethinking the parameter access hooks for plpgsql's benefit
Date
Msg-id CA+TgmoY84QSjF7DL8qWdEpwB-NBpAxcQ1smApLA=vpm7g_O0XA@mail.gmail.com
Whole thread Raw
In response to Re: Rethinking the parameter access hooks for plpgsql's benefit  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 18, 2015 at 2:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>> Seriously? In my opinion it has to be possible to doubt whether a patch
>> should be committed in certain release without it being interpreted as a
>> personal attack.
>
> I don't think anyone's said anything in this thread that amounts to a
> personal attack.  We have a difference of opinion on policy, and what
> I'm saying is that the policy ultimately reduces to trusting individual
> committers to use their best judgment.  If someone's going to tell me
> that my judgment about when to push something is not acceptable, then
> they probably ought to be calling for removal of my commit privileges.

Neither I nor anyone else is prepared to do that on the basis of what
happens to this one patch.  But if we adopt a project policy that says
a committer can ignore the contrary opinions of other people, even
when those other people include multiple other committers, this
project will not, in the long term, be successful.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Fabrízio de Royes Mello
Date:
Subject: Re: Can pg_dump make use of CURRENT/SESSION_USER
Next
From: Robert Haas
Date:
Subject: Re: Can pg_dump make use of CURRENT/SESSION_USER