Re: Rethinking the parameter access hooks for plpgsql's benefit
От | Robert Haas |
---|---|
Тема | Re: Rethinking the parameter access hooks for plpgsql's benefit |
Дата | |
Msg-id | CA+TgmoYncnq4uX7oPv+YbeFgCLBAaaWQZ1sfBEDbDQoCs6H9vA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rethinking the parameter access hooks for plpgsql's benefit (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Rethinking the parameter access hooks for plpgsql's benefit
|
Список | pgsql-hackers |
On Tue, Mar 17, 2015 at 8:01 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Tue, Mar 17, 2015 at 04:21:16PM -0700, Peter Geoghegan wrote: >> I, as a non-committer, have proposed that the rules be bent once or >> twice in the past, and those suggestions were rejected without >> exception, even though I imagined that there was a compelling >> cost/benefit ratio. I thought that was fine. I always assumed that I >> had the same right to suggest something as a committer. The only >> fundamental difference was that I had to convince a committer that my >> assessment was correct, rather than simply avoiding having the >> suggestion be vetoed. I'd need to do both. Clearly my previous >> understanding of this was questionable, to say the least. > > Basically, the same rules apply to all commitfests, i.e. a committer can > apply anything during that period. I think the only restriction for the > last commitfest is that the committer can not apply a new patch that > would have been too big to be submitted to the last commitfest. If > enough people feel that this committer behavior during the last > commitfest is a problem, we can discuss changing that policy. One thing that's crystal clear here is that we don't all agree on what the policy actually is. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: