Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)
| От | Tom Lane |
|---|---|
| Тема | Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates) |
| Дата | |
| Msg-id | 11179.1456846051@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Ответы |
Re: Commitfest Bug (was: Re: Reusing abbreviated keys
during second pass of ordered [set] aggregates)
Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates) |
| Список | pgsql-hackers |
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Magnus Hagander wrote:
>> That said, we can certainly reconsider that. Would we always copy the value
>> over? Even if it was, say, rejected? (so it would be copied to the new CF
>> but still marked rejected) Or is there a subset of behaviors you're looking
>> for?
> I think the states "Ready for Committer" and "Needs Review" ought to be
> kept in the new CF.
Definitely.
> I'm unclear on what to do about "Returned with Feedback" and "Waiting on
> Author"; my first instinct is that if a patch is in those states, then
> it shouldn't be possible to move to the next CF. On the other hand, if
> we force the state to change to "Needs Review" before moving it, we
> would lose the information of what state it was closed with. So perhaps
> for any patch in those two states, the state in the next CF should be
> "needs review" too.
+1 for not moving such patches to the new CF until the author does
something --- at which point they'd change to "Needs Review" state.
But we should not change them into that state without author input.
And I don't see the value of having them in a new CF until the
author does something.
> I am even more unclear on "Rejected". My instinct says we should refuse
> a move-to-next-cf for such patches.
Right. Rejected is dead, it shouldn't propagate forward.
regards, tom lane
В списке pgsql-hackers по дате отправления: