Commitfest: patches Ready for Committer

Started by Heikki Linnakangasover 11 years ago3 messages
#1Heikki Linnakangas
hlinnakangas@vmware.com

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Heikki Linnakangas (#1)
Re: Commitfest: patches Ready for Committer

Heikki Linnakangas <hlinnakangas@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

#3Michael Paquier
michael.paquier@gmail.com
In reply to: Tom Lane (#2)
Re: Commitfest: patches Ready for Committer

On Mon, Oct 6, 2014 at 10:53 PM, Tom Lane <tgl@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