Remove CTimeZone/HasCTZSet, root and branch.

These variables no longer have any useful purpose, since there's no reason
to special-case brute force timezones now that we have a valid
session_timezone setting for them.  Remove the variables, and remove the
SET/SHOW TIME ZONE code that deals with them.

The user-visible impact of this is that SHOW TIME ZONE will now show a
POSIX-style zone specification, in the form "<+-offset>-+offset", rather
than an interval value when a brute-force zone has been set.  While perhaps
less intuitive, this is a better definition than before because it's
actually possible to give that string back to SET TIME ZONE and get the
same behavior, unlike what used to happen.

We did not previously mention the angle-bracket syntax when describing
POSIX timezone specifications; add some documentation so that people
can figure out what these strings do.  (There's still quite a lot of
undocumented functionality there, but anybody who really cares can
go read the POSIX spec to find out about it.  In practice most people
seem to prefer Olsen-style city names anyway.)
Ensure all files created for a single BufFile have the same resource owner.

Callers expect that they only have to set the right resource owner when
creating a BufFile, not during subsequent operations on it.  While we could
insist this be fixed at the caller level, it seems more sensible for the
BufFile to take care of it.  Without this, some temp files belonging to
a BufFile can go away too soon, eg at the end of a subtransaction,
leading to errors or crashes.

Reported and fixed by Andres Freund.  Back-patch to all active branches.
Retry after buffer locking failure during SPGiST index creation.

The original coding thought this case was impossible, but it can happen
if the bgwriter or checkpointer processes decide to write out an index
page while creation is still proceeding, leading to a bogus "unexpected
spgdoinsert() failure" error.  Problem reported by Jonathan S. Katz.

Teodor Sigaev
Fix subquery reference to non-populated MV in CMV.

A subquery reference to a matview should be allowed by CREATE
MATERIALIZED VIEW WITH NO DATA, just like a direct reference is.

Per bug report from Laurent Sartran.

Backpatch to 9.3.
Acquire appropriate locks when rewriting during RMV.

Since the query has not been freshly parsed when executing REFRESH
MATERIALIZED VIEW, locks must be explicitly taken before rewrite.

Backpatch to 9.3.

Andres Freund
Changed test case slightly so it doesn't have an unused typedef.
Prevent memory leaks from accumulating across printtup() calls.

Historically, printtup() has assumed that it could prevent memory leakage
by pfree'ing the string result of each output function and manually
managing detoasting of toasted values.  This amounts to assuming that
datatype output functions never leak any memory internally; an assumption
we've already decided to be bogus elsewhere, for example in COPY OUT.
range_out in particular is known to leak multiple kilobytes per call, as
noted in bug #8573 from Godfried Vanluffelen.  While we could go in and fix
that leak, it wouldn't be very notationally convenient, and in any case
there have been and undoubtedly will again be other leaks in other output
functions.  So what seems like the best solution is to run the output
functions in a temporary memory context that can be reset after each row,
as we're doing in COPY OUT.  Some quick experimentation suggests this is
actually a tad faster than the retail pfree's anyway.

This patch fixes all the variants of printtup, except for debugtup()
which is used in standalone mode.  It doesn't seem worth worrying
about query-lifespan leaks in standalone mode, and fixing that case
would be a bit tedious since debugtup() doesn't currently have any
startup or shutdown functions.

While at it, remove manual detoast management from several other
output-function call sites that had copied it from printtup().  This
doesn't make a lot of difference right now, but in view of recent
discussions about supporting "non-flattened" Datums, we're going to
want that code gone eventually anyway.

Back-patch to 9.2 where range_out was introduced.  We might eventually
decide to back-patch this further, but in the absence of known major
leaks in older output functions, I'll refrain for now.
Get rid of more cases of the "must detoast before output function" meme.

I missed that json.c was doing this too, because for some bizarre reason
it wasn't doing it adjacent to the output function call.
Fix parsing of xlog file name in pg_receivexlog.

The parsing of WAL filenames of segments larger than > 255 was broken,
making pg_receivexlog unable to restart streaming after stopping it.

The bug was introduced by the changes in 9.3 to represent WAL segment number
as a 64-bit integer instead of two ints, log and seg. To fix, replace the
plain sscanf call with XLogFromFileName macro, which does the conversion
from log+seg to a 64-bit integer correcly.

Reported by Mika Eloranta.
Fix format code used to print dsm request sizes.

Per report from Peter Eisentraut.
Fix breakage of MV column name list usage.

Per bug report from Tomonari Katsumata.

Back-patch to 9.3.
Fix some obsolete information in src/backend/optimizer/README.

Constant quals aren't handled the same way they used to be.  Also,
add mention of a couple more major steps in grouping_planner.
Per complaint a couple months back from Etsuro Fujita.
Lock relation used to generate fresh data for RMV.

The relation should not be accessible to any other process, but it
should be locked for consistency.  Since this is not known to
cause any bug, it will not be back-patch, at least for now.

Per report from Andres Freund
Revert commit 0725065b37b8b0e9074a624a8d3e3ac1844fc820.

The previous commit was intended to make psql show the full path name when
doing a \s (history save), but it was very badly implemented and would show
confusing if not outright wrong information in many situations; for
instance if the path name given to \s is absolute, or if \cd commands
involving relative paths have been issued.  Consensus seems to be that
we don't especially need this functionality in \s, and certainly not in \s
alone.  So revert rather than trying to fix it up.  Per gripe from
Ian Barwick.

Although the bogus behavior exists in all supported versions, I'm not
back-patching, because the work created for translators (by change of
a translatable message) would probably outweigh the value of what is
after all a mostly-cosmetic change.
Improve the error message given for modifying a window with frame clause.

For rather inscrutable reasons, SQL:2008 disallows copying-and-modifying a
window definition that has any explicit framing clause.  The error message
we gave for this only made sense if the referencing window definition
itself contains an explicit framing clause, which it might well not.
Moreover, in the context of an OVER clause it's not exactly obvious that
"OVER (windowname)" implies copy-and-modify while "OVER windowname" does
not.  This has led to multiple complaints, eg bug #5199 from Iliya
Krapchatov.  Change to a hopefully more intelligible error message, and
in the case where we have just "OVER (windowname)", add a HINT suggesting
that omitting the parentheses will fix it.  Also improve the related
documentation.  Back-patch to all supported branches.
Misc GIN refactoring.

Merge the isEnoughSpace and placeToPage functions in the b-tree interface
into one function that tries to put a tuple on page, and returns false if
it doesn't fit.

Move createPostingTree function to gindatapage.c, and change its contract
so that it can be passed more items than fit on the root page. It's in a
better position than the callers to know how many items fit.

Move ginMergeItemPointers out of gindatapage.c, into a separate file.

These changes make no difference now, but reduce the footprint of Alexander
Korotkov's upcoming patch to pack item pointers more tightly.
Fix missing argument and function prototypes.

Not sure how I missed these in previous commit.
Keep heap open until new heap generated in RMV.

Early close became apparent when invalidation messages were
processed in a new location under CLOBBER_CACHE_ALWAYS builds, due
to additional locking.

Back-patch to 9.3
Support default arguments and named-argument notation for window functions.

These things didn't work because the planner omitted to do the necessary
preprocessing of a WindowFunc's argument list.  Add the few dozen lines
of code needed to handle that.

Although this sounds like a feature addition, it's really a bug fix because
the default-argument case was likely to crash previously, due to lack of
checking of the number of supplied arguments in the built-in window
functions.  It's not a security issue because there's no way for a
non-superuser to create a window function definition with defaults that
refers to a built-in C function, but nonetheless people might be annoyed
that it crashes rather than producing a useful error message.  So
back-patch as far as the patch applies easily, which turns out to be 9.2.
I'll put a band-aid in earlier versions as a separate patch.

(Note that these features still don't work for aggregates, and fixing that
case will be harder since we represent aggregate arg lists as target lists
not bare expression lists.  There's no crash risk though because CREATE
AGGREGATE doesn't accept defaults, and we reject named-argument notation
when parsing an aggregate call.)
Be more robust when strerror() doesn't give a useful result.

glibc, at least, is capable of returning "???" instead of anything useful
if it doesn't like the setting of LC_CTYPE.  If this happens, or in the
previously-known case of strerror() returning an empty string, try to
print the C macro name for the error code ("EACCES" etc).  Only if we
don't have the error code in our compiled-in list of popular error codes
(which covers most though not quite all of what's called out in the POSIX
spec) will we fall back to printing a numeric error code.  This should
simplify debugging.

Note that this functionality is currently only provided for %m in backend
ereport/elog messages.  That may be sufficient, since we don't fool with the
locale environment in frontend clients, but it's foreseeable that we might
want similar code in libpq for instance.

There was some talk of back-patching this, but let's see how the buildfarm
likes it first.  It seems likely that at least some of the POSIX-defined
error code symbols don't exist on all platforms.  I don't want to clutter
the entire list with #ifdefs, but we may need more than are here now.

MauMau, edited by me