[HACKERS] Commitfest: patches Ready for Committer
In addition to the few patches left in Needs Review state, we have six patches marked as Ready for Committer. Committers: Could you please pick a patch, and commit if appropriate? Or if there's a patch there that you think should *not* be committed, please speak up. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest: patches Ready for Committer
Heikki Linnakangas hlinnakan...@vmware.com writes: Committers: Could you please pick a patch, and commit if appropriate? Or if there's a patch there that you think should *not* be committed, please speak up. The custom plan API thing may be marked ready for committer, but that doesn't mean it's committable, or even that there is any consensus about whether we want it or what it should look like. The levenshtein-distance thingy seems to still be a topic of debate as well, both as to how we're going to refactor the code and as to what the exact hinting rules ought to be. If some committer wants to take charge of it and resolve those issues, fine; but I don't want to see it done by just blindly committing whatever the last submitted version was. I've not paid much of any attention to the other four. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest: patches Ready for Committer
On Mon, Oct 6, 2014 at 10:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: The levenshtein-distance thingy seems to still be a topic of debate as well, both as to how we're going to refactor the code and as to what the exact hinting rules ought to be. If some committer wants to take charge of it and resolve those issues, fine; but I don't want to see it done by just blindly committing whatever the last submitted version was. My 2c. I imagine that in this case the consensus is going to be first: - Move a minimum of the core functions of fuzzystrmatch and rename them (str_distance?) - Do not dump fuzzystrmatch and have the levenshtein call those functions In any case levenshtein code needs a careful refactoring and some additional thoughts first before the hint code is touched. Regards. -- Michael
