Re: Patch to support SEMI and ANTI join removal
От | Andres Freund |
---|---|
Тема | Re: Patch to support SEMI and ANTI join removal |
Дата | |
Msg-id | 20150213081256.GA5602@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Patch to support SEMI and ANTI join removal (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Patch to support SEMI and ANTI join removal
|
Список | pgsql-hackers |
On 2015-02-13 17:06:14 +0900, Michael Paquier wrote: > On Fri, Feb 13, 2015 at 4:57 PM, Marko Tiikkaja <marko@joh.to> wrote: > > > On 2/13/15 8:52 AM, Michael Paquier wrote: > > > >> On Sun, Nov 23, 2014 at 8:23 PM, David Rowley <dgrowleyml@gmail.com> > >> wrote: > >> > >>> As the patch stands there's still a couple of FIXMEs in there, so there's > >>> still a bit of work to do yet. > >>> Comments are welcome > >>> > >>> > >> Hm, if there is still work to do, we may as well mark this patch as > >> rejected as-is, also because it stands in this state for a couple of > >> months. > >> > > > > I didn't bring this up before, but I'm pretty sure this patch should be > > marked "returned with feedback". From what I've understood, "rejected" > > means "we don't want this thing, not in this form or any other". That > > doesn't seem to be the case for this patch, nor for a few others marked > > "rejected" in the currently in-progress commit fest. > > > > In the new CF app, marking a patch as "returned this feedback" adds it > automatically to the next commit fest. And note that it is actually what I > did for now to move on to the next CF in the doubt: > https://commitfest.postgresql.org/3/27/ > But if nothing is done, we should as well mark it as "rejected". Not based > on the fact that it is rejected based on its content, but to not bloat the > CF app with entries that have no activity for months. Then the CF app needs to be fixed. Marking patches as rejected on these grounds is a bad idea. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: