Wikimedia Bugzilla is closed!

I recently upgraded my wiki (PostgreSQL back-end) to version 1.10.0 using the
official upgrade method - i.e. running the update.php script with the PHP 5.2
CLI. The Wiki works but the search fails. This is a critical bug because a wiki
is useless without search!

I enabled $wgShowExceptionDetails and found more information on the error:
"ERROR: unrecognized normalization method: 5". A quick read of the query showed
that the script was trying to send "5" as the "normalization" parameter to
Tsearch2's "rank()" method. (Parm. 3)

Some research into TSearch2 shows that only three options are available for this
parameter:
    * 0 (the default) ignores document length.
    * 1 divides the rank by the logarithm of the length.
    * 2 divides the rank by the length itself. 
(Confirming my suspicions, I've used TSearch2 before...)
(Cut and Paste from http://www.rhodesmill.org/brandon/projects/tsearch2-ref.html)

Thinking that OpenFTS might have introduced more normalization options, I
checked the OpenFTS documentation. This did not reveal a solution - OpenFTS'
docs agree with the Tsearch2 docs.

Grep'ping around inside MediaWiki reveals the offending line to be line 144 of
includes/SearchPostgres.php which is hard-coded to send a value of 5 here.

I immediately suspected a bug introduced by the upgrade process (as I said, I
had upgraded (from 1.8, I think)) and checked the original archive of files I
downloaded from SourceForge - the file is identical. This bug was not caused by
a failure to update this individual file. While checking the original archive, I
did notice the existance of an includes/SearchTsearch2.php file. I was not sure
what that file was there for, so I examined it.

Within includes/SearchTsearch2.php, the rank() method is called with only 2
parameters. Hmm... interesting...

I tried two solutions.

First, I changed this "5" (line 144) to "2" (a non-default value I chose
willy-nilly from the three available choices) and saved
includes/SearchPostgres.php. The search succeeded. This solution poses three
questions:
    a) Why is there a 5 in the released code? Is it a genuine bug or am I
missing something?
    b) What *should* this value be, assuming it should not be 5?
    c) Could the fix be this simple? (That was *way* too easy.)

Secondly, I tried to find where "SearchPostgres" was being specified as the
search engine (hook) to use, intending to change it to SearchTsearch2 and see
what happens. I found the only reference to "SearchPostgres.php" on line 156 of
includes/AutoLoader.php. Killing this line broke the search function entirely.
(class 'SearchPostgres' not found.) Duh. (Spontaneous, quirky wish: must create
aliases for grep, called "grp" and "gre") Replacing the line with:
    'SearchTsearch2' => 'includes/SearchTsearch2.php',
... also did not work, until I changed 'SearchPostgres' to 'SearchTsearch2' on
line 215 of includes/SearchEngine.php. Sadly, while this caused the search to
run, no results where returned for my search terms.

Clearly the only solution is to change the 5 to something else (0, 1 or 2) on
line 144 of includes/SearchPostgres.php.

Am I missing something?
Can someone confirm this bug and this proposed solution?
What *is* the correct value? 0, 1 or 2?

P.S. Please forgive the stream-of-consciousness debugging technique. It works.