Postgres updates for 4.6

By the way, here's a note to keep tabs on a search issue:

Search stores scores and totals for words. These are all integers.

But in the search results query, I use SUM(score/total) and it is intended that the division is done without rounding, i.e. with floating point numbers. MySQL automatically does this, but I believe PGSQL will truncate the result back to an integer. This is bad as every value of score/total is 0 < x < 1 and would thus be truncated to zero.

Of course we could change the column types to floats instead, but I'm not sure this is a good idea.

I committed this patch. No marking this 'fixed' yet.

The following change seems wrong to me:
- $query = "SELECT i.type, i.sid, i.word, SUM(i.score/t.count) AS score FROM {search_index} i $join INNER JOIN {search_total} t ON i.word = t.word WHERE $where GROUP BY i.type, i.sid ORDER BY score DESC";
+ $query = "SELECT i.type, i.sid, i.word, SUM(i.score/t.count) AS score FROM {search_index} i $join INNER JOIN {search_total} t ON i.word = t.word WHERE $where GROUP BY i.type, i.sid, i.word ORDER BY score DESC";

This will cause the search scores to be calculated and returned per word rather than as a sum of all matching words. The i.word field that is being selected is actually unnecessary. It is cruft from during development.

I think the following will work:
$query = "SELECT i.type, i.sid, SUM(i.score/t.count) AS score FROM {search_index} i $join INNER JOIN {search_total} t ON i.word = t.word WHERE $where GROUP BY i.type, i.sid ORDER BY score DESC";

I committed part of this patch:

1. Removed a duplicate line from the changes to update.inc.
2. Excluded the session.inc changes: they did not make sense to me.
3. Excluded the search related changes in the node and search module. According to Steven these are not correct.

Wouldn't $user->uid always be NULL or zero? The $user object has not been initialized at that point.

Fixed in HEAD.