json_build_object and json_build_array are stable, not immutable.

These functions indirectly invoke output functions, so they can't be
immutable.

Backpatch to 9.4 where they were introduced.

Catalog version bumped.
pg_basebackup: Add more information about --max-rate option to help output

It was previously not clear what unit the option argument should have.
pg_upgrade: Fix spacing in help output
doc: Put new options in right order on reference pages
Third review of Christoph Berg
Move check for SSL_get_current_compression to run on mingw

Mingw uses a different header file than msvc, so we don't get the
hardcoded value, so we need the configure test to run.
Allow join removal in some cases involving a left join to a subquery.

We can remove a left join to a relation if the relation's output is
provably distinct for the columns involved in the join clause (considering
only equijoin clauses) and the relation supplies no variables needed above
the join.  Previously, the join removal logic could only prove distinctness
by reference to unique indexes of a table.  This patch extends the logic
to consider subquery relations, wherein distinctness might be proven by
reference to GROUP BY, DISTINCT, etc.

We actually already had some code to check that a subquery's output was
provably distinct, but it was hidden inside pathnode.c; which was a pretty
bad place for it really, since that file is mostly boilerplate Path
construction and comparison.  Move that code to analyzejoins.c, which is
arguably a more appropriate location, and is certainly the site of the
new usage for it.

David Rowley, reviewed by Simon Riggs
Fix bugs in SP-GiST search with range type's -|- (adjacent) operator.

The consistent function contained several bugs:

* The "if (which2) { ... }"  block was broken. It compared the  argument's
lower bound against centroid's upper bound, while it was supposed to compare
the argument's upper bound against the centroid's lower bound (the comment
was correct, code was wrong). Also, it cleared bits in the "which1"
variable, while it was supposed to clear bits in "which2".

* If the argument's upper bound was equal to the centroid's lower bound, we
descended to both halves (= all quadrants). That's unnecessary, searching
the right quadrants is sufficient. This didn't lead to incorrect query
results, but was clearly wrong, and slowed down queries unnecessarily.

* In the case that argument's lower bound is adjacent to the centroid's
upper bound, we also don't need to visit all quadrants. Per similar
reasoning as previous point.

* The code where we compare the previous centroid with the current centroid
should match the code where we compare the current centroid with the
argument. The point of that code is to redo the calculation done in the
previous level, to see if we were supposed to traverse left or right (or up
or down), and if we actually did. If we moved in the different direction,
then we know there are no matches for bound.

Refactor the code and adds comments to make it more readable and easier to
reason about.

Backpatch to 9.3 where SP-GiST support for range types was introduced.
merge master