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

From Tom Lane
Subject Re: Rethinking the parameter access hooks for plpgsql's benefit
Date
Msg-id 29654.1426701701@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rethinking the parameter access hooks for plpgsql's benefit  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Rethinking the parameter access hooks for plpgsql's benefit  (Robert Haas <robertmhaas@gmail.com>)
Re: Rethinking the parameter access hooks for plpgsql's benefit  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Strange assertion using VACOPT_FREEZE in vacuum.c
Next
From: Alvaro Herrera
Date:
Subject: Re: Add LINE: hint when schemaname.typename is a non-existent schema