Since C99, it's been standard for printf and friends to accept a "z" size
modifier, meaning "whatever size size_t has".  Up to now we've generally
dealt with printing size_t values by explicitly casting them to unsigned
long and using the "l" modifier; but this is really the wrong thing on
platforms where pointers are wider than longs (such as Win64).  So let's
start using "z" instead.  To ensure we can do that on all platforms, teach
src/port/snprintf.c to understand "z", and add a configure test to force
use of that implementation when the platform's version doesn't handle "z".

Having done that, modify a bunch of places that were using the
unsigned-long hack to use "z" instead.  This patch doesn't pretend to have
gotten everyplace that could benefit, but it catches many of them.  I made
an effort in particular to ensure that all uses of the same error message
text were updated together, so as not to increase the number of
translatable strings.

It's possible that this change will result in format-string warnings from
pre-C99 compilers.  We might have to reconsider if there are any popular
compilers that will warn about this; but let's start by seeing what the
buildfarm thinks.

Andres Freund, with a little additional work by me

make maintainer-check was obscure and rarely called in practice, and
many breakages were missed.  Fold everything that make maintainer-check
used to do into the normal build.  Specifically:

- Call duplicate_oids when genbki.pl is called.

- Check for tabs in SGML files when the documentation is built.

- Run msgfmt with the -c option during the regular build.  Add an
  additional configure check to see whether we are using the GNU
  version.  (make maintainer-check probably used to fail with non-GNU
  msgfmt.)

Keep maintainer-check as around as phony target for the time being in
case anyone is calling it.  But it won't do anything anymore.

This is just neatnik-ism, since all the tests in the code are #ifdefs,
but we shouldn't specify symbols as "Define to 1 ..." and then not
actually define them that way.

Ants Aasma and Jeff Davis

In commit 71450d7f, we added code to inform
suitably-intelligent compilers that ereport() doesn't return if the elevel
is ERROR or higher.  This patch extends that to elog(), and also fixes a
double-evaluation hazard that the previous commit created in ereport(),
as well as reducing the emitted code size.

The elog() improvement requires the compiler to support __VA_ARGS__, which
should be available in just about anything nowadays since it's required by
C99.  But our minimum language baseline is still C89, so add a configure
test for that.

The previous commit assumed that ereport's elevel could be evaluated twice,
which isn't terribly safe --- there are already counterexamples in xlog.c.
On compilers that have __builtin_constant_p, we can use that to protect the
second test, since there's no possible optimization gain if the compiler
doesn't know the value of elevel.  Otherwise, use a local variable inside
the macros to prevent double evaluation.  The local-variable solution is
inferior because (a) it leads to useless code being emitted when elevel
isn't constant, and (b) it increases the optimization level needed for the
compiler to recognize that subsequent code is unreachable.  But it seems
better than not teaching non-gcc compilers about unreachability at all.

Lastly, if the compiler has __builtin_unreachable(), we can use that
instead of abort(), resulting in a noticeable code savings since no
function call is actually emitted.  However, it seems wise to do this only
in non-assert builds.  In an assert build, continue to use abort(), so that
the behavior will be predictable and debuggable if the "impossible"
happens.

These changes involve making the ereport and elog macros emit do-while
statement blocks not just expressions, which forces small changes in
a few call sites.

Andres Freund, Tom Lane, Heikki Linnakangas

This means we can now construct a configure test for the library
presence. Previously these parameters were only figured out at
build time in plperl's GnuMakefile.

Pre-Lion versions of Apple's linker don't allow space between -F and its
argument.  (Snow Leopard is nice enough to tell you that in so many words,
but older versions just fail with very obscure link errors, as seen on
buildfarm member locust for instance.)  Oversight in commit
fc874507.

The PL/Python build on OS X was previously hardcoded to use the system
installation of Python, ignoring whatever was specified to configure.
Except that it would use the header files from configure, which could
lead to mismatches.  It was not possible to build against a custom
Python installation.

Now, we check in configure how the specified Python installation was
built and use that, supporting framework and non-framework builds.

The former name was too likely to conflict with symbols from external
headers; and, as seen in recent buildfarm failures in member spoonbill,
it has now happened at least in plpython.

Currently, the macros only work with fairly recent gcc versions, but there
is room to expand them to other compilers that have comparable features.

Heavily revised and autoconfiscated version of a patch by Andres Freund.

Python can be built to have two separate include directories: one for
platform-independent files and one for platform-specific files.  So
far, this has apparently never mattered for a PL/Python build.  But
with the new multi-arch Python packages in Debian and Ubuntu, this is
becoming the standard configuration on these platforms, so we must
check these directories separately to be able to build there.

Also add a bit of reporting in configure to be able to see better what
is going on with this.

There was a hack put into install-sh to call strip with the correct
options on Mac OS X.  But that never worked, because configure
disabled stripping on that platform altogether.  So remove that dead
code, and while we're at it, update install-sh to the latest upstream
source (from Automake).

Instead, set up the right strip options in programs.m4, so this now
actually works the way it was originally intended.

The BSD-ish members of the buildfarm all seem to think removing this
was a bad idea.  It looks to me like it resulted in omitting the system
header inclusion necessary to detect the fields of struct tm correctly.

ENABLE_DTRACE            unused as of a7b7b07a
HAVE_ERR_SET_MARK        unused as of 4ed4b6c5
HAVE_FCVT                unused as of 4553e1d8
HAVE_STRUCT_SOCKADDR_UN  unused as of b4cea00a
HAVE_SYSCONF             unused as of f83356c7
TM_IN_SYS_TIME           never used, obsolescent per Autoconf documentation

PGAC_PATH_COLLATEINDEX supposed that it could use AC_PATH_PROGS to search
for collateindex.pl, but that macro will only accept files that are marked
executable, and at least some DocBook installations don't mark the script
executable (a case the docs Makefile was already prepared for).  Accept the
script if it's present and readable in $DOCBOOKSTYLE/bin, and otherwise
search the PATH as before.

Having fixed that up, we don't need the fallback case that was in the docs
Makefile, and instead can throw an understandable error if configure didn't
find the script.  Per recent trouble report from John Lumby.

According to Chris Rees, this has worked for awhile, and the current
FreeBSD port is removing the test anyway.

Original patch by Lars Kanis, reviewed by Nishiyama Tomoaki and tweaked some by me.

This compiler, or at least the latest version of it, is currently broken, and
only passes the regression tests if built with -O0.

They have been unneeded since the use of the string module has been
removed in a65ed83f.

Because of ABI tagging, the library version number might no longer be
exactly the Python version number, so do extra lookups.  This affects
installations without a shared library, such as ActiveState's
installer.

Also update the way to detect the location of the 'config' directory,
which can also be versioned.

Ashesh Vashi

This is reported to be necessary on some versions of that OS.  In service
of this, cause PGAC_PROG_CC_CFLAGS_OPT to reject switches that result in
compiler warnings, since on yet other versions of that OS, the switch does
nothing except provoke a warning.

Report and patch by Ibrar Ahmed, further tweaking by me.

When testing the stderr produced by various thread-support flags, also
run a compilation in addition to a link, because clang warns on
certain flags when compiling but not when linking.

This adds collation support for columns and domains, a COLLATE clause
to override it per expression, and B-tree index support.

Peter Eisentraut
reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch

This can be used to build 64 bit Windows binaries, not only on 64 bit
Windows but on supported cross-compiling hosts including 32 bit Windows,
Cygwin, Darwin and Linux.

Per previous failure of buildfarm member koi (which is no longer
failing, alas).

them after the fact.  This is a more elegant fix for bug #5595.

These are just cosmetic and don't seem worth back-patching far.
I put them into 9.0 just because it was trivial to do so.

build tree.  If we actually build the docs in the VPATH tree, those dirs
will get created then; but if they're present and empty, they capture the
vpathsearch searches in "make install", preventing installation of prebuilt
docs that might exist in the source tree.  Per bug #5595 from Dmtiriy Igrishin.
Fix based on idea from Peter Eisentraut.

at end of files.

Added a configure test for "long long" datatypes. So far this is only used in ecpg and replaces the old test that was kind of hackish.

This variable is apparently only for Python internally.  In newer releases
of Python this variable pulls in more and more libraries that users are
less likely to have, leading to potential build failures.

output.  Per bug #5339, Perl 5.11 has changed the format of that output
enough to break the previous coding.

Alex Hunsaker