remove from local *.h files.

Per suggestion from Alvaro.

.h include files before .c files.

Mark some includes as needed to be ignored by pgrminclude.

tsvector_concat() allocated its result workspace using the "conservative"
estimate of the sum of the two input tsvectors' sizes.  Unfortunately that
wasn't so conservative as all that, because it supposed that the number of
pad bytes required could not grow.  Which it can, as per test case from
Jesper Krogh, if there's a mix of lexemes with positions and lexemes
without them in the input data.  The fix is to assume that we might add
a not-previously-present pad byte for each and every lexeme in the two
inputs; which really is conservative, but it doesn't seem worthwhile to
try to be more precise.

This is an aboriginal bug in tsvector_concat, so back-patch to all
versions containing it.

These changes allow backtick command evaluation and psql variable
interpolation to happen on substrings of a single meta-command argument.
Formerly, no such evaluations happened at all if the backtick or colon
wasn't the first character of the argument, and we considered an argument
completed as soon as we'd processed one backtick, variable reference, or
quoted substring.  A string like 'FOO'BAR was thus taken as two arguments
not one, not exactly what one would expect.  In the new coding, an argument
is considered terminated only by unquoted whitespace or backslash.

Also, clean up a bunch of omissions, infelicities and outright errors in
the psql documentation of variables and metacommand argument syntax.

As in the backend, the implementation actually accepts any non-ASCII
character, but we only document that you can use letters.

flex puts lex.backup in the current working directory regardless
of where the input and output are.

#if/#ifdefs.

introduced recently when trying to filter out temp tables.

Backpatch to 9.0 and 9.1.

This was deemed unnecessary initially but in later discussion it was
agreed otherwise.

Original file from Kevin Grittner, allegedly from Dan Ports.
I had to clean up whitespace a bit per changes from Heikki.

Per discussion, we should enforce the policy of "no backtracking" in these
performance-sensitive scanners.

Per previous experimentation, backtracking slows down lexing performance
significantly (by about a third).  It's usually pretty easy to avoid, just
need to have rules that accept an incomplete construct and do whatever the
lexer would have done otherwise.

The backtracking was introduced by the patch that added quoted variable
substitution.  Back-patch to 9.0 where that was added.

This is recommended in the flex manual, and there seems no good reason
not to use it everywhere.

Rather than dumping out the raw array as PostgreSQL represents it
internally, we now print it out in a format similar to the one in
which the user input it, which seems a lot more user friendly.

Shigeru Hanada

Shigeru Hanada

This makes it slightly more clear that '*' is not part of the default
value, in case that wasn't obvious.

As requested by Dougal Sutherland.

Noted by Hitoshi Harada.

This is mainly to prove that the NaN fix actually works cross-platform.

For an empty index, the pgstatindex() function would compute 0.0/0.0 for
its avg_leaf_density and leaf_fragmentation outputs.  On machines that
follow the IEEE float arithmetic standard with any care, that results in
a NaN.  However, per report from Rushabh Lathia, Microsoft couldn't
manage to get this right, so you'd get a bizarre error on Windows.

Fix by forcing the results to be NaN explicitly, rather than relying on
the division operator to give that or the snprintf function to print it
correctly.  I have some doubts that this is really the most useful
definition, but it seems better to remain backward-compatible with
those platforms for which the behavior wasn't completely broken.

Back-patch to 8.2, since the code is like that in all current releases.

With these changes, the isolation tests pass again on isolation levels
serializable and repeatable read.

Author: Kevin Grittner

The previous coding resulted in contrib modules unintentionally overriding
the use of CONTRIB_TESTDB.  There seems no particularly good reason to
allow that (after all, the makefile can set CONTRIB_TESTDB if that's really
what it intends).

In passing, document REGRESS_OPTS where the other pgxs.mk options are
documented.

Back-patch to 9.1 --- in prior versions, there were no cases of contrib
modules setting REGRESS_OPTS without including the --dbname switch, so
while the coding was fragile there was no actual bug.

This fixes failures under parallel make when contrib modules use a
generated backend header file (such as errcodes.h).

We'll have to settle for just listing the extensions' data types,
since function arguments seem to sort differently in different locales.
Per buildfarm results.

When we implemented extensions, we made findDependentObjects() treat
EXTENSION dependency links similarly to INTERNAL links.  However, that
logic contained an implicit assumption that an object could have at most
one INTERNAL dependency, so it did not work correctly for objects having
both INTERNAL and DEPENDENCY links.  This led to failure to drop some
extension member objects when dropping the extension.  Furthermore, we'd
never actually exercised the case of recursing to an internally-referenced
(owning) object from anything other than a NORMAL dependency, and it turns
out that passing the incoming dependency's flags to the owning object is
the Wrong Thing.  This led to sometimes dropping a whole extension silently
when we should have rejected the drop command for lack of CASCADE.

Since we obviously were under-testing extension drop scenarios, add some
regression test cases.  Unfortunately, such test cases require some
extensions (duh), so we can't test for problems in the core regression
tests.  I chose to add them to the earthdistance contrib module, which is
a good test case because it has a dependency on the cube contrib module.

Back-patch to 9.1.  Arguably these are pre-existing bugs in INTERNAL
dependency handling, but since it appears that the cases can never arise
pre-9.1, I'll refrain from back-patching the logic changes further than
that.

When creating a new schema for a non-relocatable extension, we neglected
to check whether the calling user has permission to create schemas.
That didn't matter in the original coding, since we had already checked
superuserness, but in the new dispensation where users need not be
superusers, we should check it.  Use CreateSchemaCommand() rather than
calling NamespaceCreate() directly, so that we also enforce the rules
about reserved schema names.

Per complaint from KaiGai Kohei, though this isn't the same as his patch.

set_append_rel_pathlist supposed that, while computing per-column width
estimates for the appendrel, it could ignore child rels for which the
translated reltargetlist entry wasn't a Var.  This gave rise to completely
silly estimates in some common cases, such as constant outputs from some or
all of the arms of a UNION ALL.  Instead, fall back on get_typavgwidth to
estimate from the value's datatype; which might be a poor estimate but at
least it's not completely wacko.

That problem was exposed by an Assert in set_subquery_size_estimates, which
unfortunately was still overoptimistic even with that fix, since we don't
compute attr_widths estimates for appendrels that are entirely excluded by
constraints.  So remove the Assert; we'll just fall back on get_typavgwidth
in such cases.

Also, since set_subquery_size_estimates calls set_baserel_size_estimates
which calls set_rel_width, there's no need for set_subquery_size_estimates
to call get_typavgwidth; set_rel_width will handle it for us if we just
leave the estimate set to zero.  Remove the unnecessary code.

Per report from Erik Rijkers and subsequent investigation.