Document that CREATE INDEX CONCURRENTLY is not currently supported for
indexes on partitioned tables.

Discussion: https://postgr.es/m/CAKJS1f_CErd2z9L21Q8OGLD4TgH7yw1z9MAtHTSO13sXVG-yow@mail.gmail.com
Backpatch-through: 11

Formal tables should generally have an xref in the text that points to
them.  Add them here.

When performing REINDEX TABLE CONCURRENTLY, if all of the table's indexes
could not be reindexed, a NOTICE message claimed that the table had no
indexes.  This was confusing, so let's change the NOTICE text to something
less confusing.

In passing, also mention in the comment before ReindexRelationConcurrently
that materialized views are supported too and also explain what the return
value of the function means.

Author: Ashwin Agrawal
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CALfoeithHvi13p_VyR8kt9o6Pa7Z=Smi6Nfc2anHnQx5Lj8bTQ@mail.gmail.com

86b85044 rewrote how COPY FROM works to allow multiple tuple buffers to
exist to once thus allowing multi-inserts to be used in more cases with
partitioned tables.  That commit neglected to update the estate's
es_result_relation_info when flushing the insert buffer to the partition
making it possible for the index tuples to be added into an index on the
wrong partition.

Fix this and also add an Assert in ExecInsertIndexTuples to help ensure
that we never make this mistake again.

Reported-by: Haruka Takatsuka
Author: Ashutosh Sharma
Discussion: https://postgr.es/m/15832-b1bf336a4ee246b5@postgresql.org

When merging two attributes, we are sure that at least one remains.
However, when deleting one element in the attribute list we may finish
with an empty list returned as NIL by list_delete_cell(), but the code
failed to track that, which is not project-like.  Adjust the call so as
we check for an empty list, and make use of it in an assertion.

This has been introduced by e7b3349a, when adding support for CREATE
TABLE OF.

Author: Mark Dilger
Reviewed-by: Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/CAE-h2TpPDqSWgOvfvSziOaMngMPwW+QZcmPpY8hQ_KOJ2+3hXQ@mail.gmail.com

Continuous operation cannot be achieved without applying this technique,
so it needs to be properly described.

Author: Álvaro Herrera
Reported-by: Tom Lane
Discussion: https://postgr.es/m/8756.1556302759@sss.pgh.pa.us

Verbatim environment tags should not be indented.

This allows determining which command is running, similar to
pg_stat_progress_cluster.

Discussion: https://www.postgresql.org/message-id/flat/f0e56b3b-74b7-6cbc-e207-a5ed6bee18dc%402ndquadrant.com

The defined callback definitions have been using references to heap for
a couple of variables and comments.  This makes the whole interface more
consistent by using "table" which is more generic.

A variable storing index information was misspelled as well.

Author: Michael Paquier
Discussion: https://postgr.es/m/20190601190946.GB1905@paquier.xyz

A parallel worker process should not be making any decisions of its
own about whether to auto-explain.  If the parent session process
passed down flags asking for instrumentation data, do that, otherwise
not.  Trying to enable instrumentation anyway leads to bugs like the
"could not find key N in shm TOC" failure reported in bug #15821
from Christian Hofstaedtler.

We can implement this cheaply by piggybacking on the existing logic
for not doing anything when we've chosen not to sample a statement.

While at it, clean up some tin-eared coding related to the sampling
feature, including an off-by-one error that meant that asking for 1.0
sampling rate didn't actually result in sampling every statement.

Although the specific case reported here only manifested in >= v11,
I believe that related misbehaviors can be demonstrated in any version
that has parallel query; and the off-by-one error is certainly there
back to 9.6 where that feature was added.  So back-patch to 9.6.

Discussion: https://postgr.es/m/15821-5eb422e980594075@postgresql.org

It's not really supported to call systable_getnext() in a different
memory context than systable_beginscan() was called in, and it's
*definitely* not safe to do so and then reset that context between
calls.  I'm not very clear on how this code survived
CLOBBER_CACHE_ALWAYS testing ... but Alexander Lakhin found a case
that would crash it pretty reliably.

Per bug #15828.  Fix, and backpatch to v11 where this code came in.

Discussion: https://postgr.es/m/15828-f6ddd7df4852f473@postgresql.org

Reviewed-by: Oleg Bartunov <obartunov@postgrespro.ru>

Author: Andrea Gelmini
Reviewed-by: Michael Paquier, Justin Pryzby
Discussion: https://postgr.es/m/20190528181718.GA39034@glet

The following issues have been spotted:
- CREATE INDEX .. USING suggests both index and table AMs, but it should
consider only index AMs.
- CREATE TABLE .. USING has no completion support.  USING was not being
included in the completion list where it should, and follow-up
suggestions for table AMs have been missing as well.
- CREATE ACCESS METHOD .. TYPE suggests only INDEX, with TABLE missing.

Author: Michael Paquier
Discussion: https://postgr.es/m/20190601191007.GC1905@paquier.xyz

Teach it to scrape -I and -D switches from CPPFLAGS in Makefile.global.
This is useful for testing on, eg, FreeBSD, where you won't get far
without "-I/usr/local/include".

Also, expand the set of blacklisted-for-unportability atomics headers,
based on noting that arch-x86.h fails to compile on an ARM box.  The
other ones I'd omitted seem to compile all right on architectures they
don't belong to, but that's surely too shaky to rely on.  Let's do
like we did for the src/include/port/ headers, and ignore all except
the variant that's pulled in by the arch-independent header.

Perl likes to redefine the _() macro:

#ifdef CAN_PROTOTYPE
#define	_(args) args
#else ...

There was lots not to like about the way we dealt with this before:

1. Instead of taking care of the conflict centrally in plperl.h, we
expected every one of its ever-growing number of includers to do so.
This is duplicative and error-prone in itself, plus it means that
plperl.h fails to meet the expectation of being compilable standalone,
resulting in macro-redefinition warnings in cpluspluscheck.

2. We left _() with its Perl definition, meaning that if someone tried
to use it in any Perl-related extension, it would silently fail to
provide run-time translation.  I don't see any live bugs of this ilk,
but it's clearly a hard-to-notice bug waiting to happen.

So fix that by centralizing the cleanup logic, making it match what
we're already doing for other macro conflicts with Perl.  Since we only
expect plperl.h to be included by extensions not core code, we should
redefine _() as dgettext() not gettext().

Declaring a function "inline" still doesn't work with Windows compilers
(C99? what's that?), unless the macro provided by pg_config.h is
in-scope, which it is not in our ECPG test programs.  So the workaround
I tried to use in commit 7640f931 doesn't work for Windows.  Revert
the change in printf_hack.h, and instead just blacklist that file
in cpluspluscheck --- since it's a not-installed test file, we don't
really need to verify its C++ cleanliness anyway.

This test module was not getting invoked, other than at compile time,
limiting its usefulness -- and keeping its coverage at 0%.  Add a
minimal regression test to ensure it runs on make check-world; this
makes it 92% covered (line-wise), which seems sufficient.

Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/20190529193256.GA17603@alvherre.pgsql

Support of CHECK OPTION for updatable views has been added in 9.4, but
the documentation of information_schema never got the call even if the
information displayed is correct.

Author: Gilles Darold
Discussion: https://postgr.es/m/75d07704-6c74-4f26-656a-10045c01a17e@darold.net
Backpatch-through: 9.4

Formerly, cpluspluscheck was only meant to examine headers that
we thought of as exported --- but its notion of what we export
was well behind the times.  Let's just make it check *all* .h
files, except for a well-defined blacklist, instead.

While at it, improve its ability to use a C++ compiler other than g++,
by scraping the CXX setting from Makefile.global and making it possible
to override the warning options used (per suggestion from Andres Freund).

Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru

Previously cpluspluscheck wouldn't work in vpath builds, this commit
fixes that. To make it easier to invoke, there's a top-level
cpluspluscheck target.

Discussion: https://postgr.es/20190530220244.kiputcbl4gkl2oo6@alap3.anarazel.de

Author: Antonin Houska
Discussion: https://postgr.es/m/22370.1559293357@localhost

Mea culpa for not rechecking check-world at the last step :-(
Per buildfarm.

There's probably no need to back-patch this, since it seems unlikely
that anybody would be inserting C++ code into ecpg's preprocessor.

Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru

Rename some exposed parameters so that they don't conflict with
C++ reserved words.

Back-patch to all supported versions.

George Tarasov

Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru

We have a longstanding project convention that all .h files should
be includable with no prerequisites other than postgres.h.  This is
tested/relied-on by cpluspluscheck.  However, cpluspluscheck has not
historically been applied to most headers outside the src/include
tree, with the predictable consequence that some of them don't work.
Fix that, usually by adding missing #include dependencies.

The change in printf_hack.h might require some explanation: without
it, my C++ compiler whines that the function is unused.  There's
not so many call sites that "inline" is going to cost much, and
besides all the callers are in test code that we really don't care
about the size of.

There's no actual bugs being fixed here, so I see no need to back-patch.

Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru

While C is happy to cast "const void *" to "const unsigned char *"
silently, C++ insists on an explicit cast.  Since we put these
functions into header files, cpluspluscheck whines about that.
Add the cast to pacify it.

Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru

New in 147e3722.

This makes the tool consistent with the option set of oid2name, which
has been historically using -f for filenodes, and has more recently
gained long options and --filenode via 1aaf532d.

Reported-by: Peter Eisentraut
Author: Fabien Coelho
Discussion: https://postgr.es/m/97045260-fb9e-e145-a950-cf7d28c4eaea@2ndquadrant.com

Interestingly only C++ compilers have, so far, complained about this
odd forward declaration. This originated when IndexBuildCallback was
defined in another file, but now is completely unnecessary (but was
wrong before too, cpluspluscheck just wouldn't have noticed).

Reported-By: Tom Lane
Discussion: https://postgr.es/m/53941.1559239260@sss.pgh.pa.us

Most errors reported in extended statistics are internal issues, and so
should use elog(). The MCV list code was already following this rule, but
the functional dependencies and ndistinct coefficients were using a mix
of elog() and ereport(). Fix this by changing most places to elog(), with
the exception of input functions.

This is a mostly cosmetic change, it makes the life a little bit easier
for translators, as elog() messages are not translated. So backpatch to
PostgreSQL 10, where extended statistics were introduced.

Author: Tomas Vondra
Backpatch-through: 10 where extended statistics were added
Discussion: https://postgr.es/m/20190503154404.GA7478@alvherre.pgsql

Author: Guillaume Lelarge
Discussion: https://postgr.es/m/CAECtzeWPz4JikzUqZdMjqPTe8dAP3nZxPD-58Y-Hhvirg0fF+A@mail.gmail.com

This got forgotten in f56f8f which has added foreign key support for
partitioned tables.  In passing, add a mention about caveats applying to
tables partitioned using inheritance regarding indexes and foreign keys.

Author: Paul A Jungwirth
Reviewed-by: Amit Langote, Michael Paquier
Discussion: https://postgr.es/m/CA+renyUuSmYgmZjKc_DfUNVZ0uttF91-FwhDVW3F7WEPj0jL5w@mail.gmail.com

I introduced the typo in source code in the course of 75445c15.
Repair.

When this suite runs installcheck, redirect file creations from
src/test/regress to src/bin/pg_upgrade/tmp_check/regress.  This closes a
race condition in "make -j check-world".  If the pg_upgrade suite wrote
to a given src/test/regress/results file in parallel with the regular
src/test/regress invocation writing it, a test failed spuriously.  Even
without parallelism, in "make -k check-world", the suite finishing
second overwrote the other's regression.diffs.  This revealed test
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.

Buildfarm client REL_10, released fifty-four days ago, supports saving
regression.diffs from its new location.  When an older client reports a
pg_upgradeCheck failure, it will no longer include regression.diffs.
Back-patch to 9.5, where pg_upgrade moved to src/bin.

Reviewed (in earlier versions) by Andrew Dunstan.

Discussion: https://postgr.es/m/20181224034411.GA3224776@rfd.leadboat.com

This allows "vcregress upgradecheck" to pass twice in immediate
succession, and it's more like how $(prove_check) works.  Back-patch to
9.5, where pg_upgrade moved to src/bin.

Discussion: https://postgr.es/m/20190520012436.GA1480421@rfd.leadboat.com

Mea culpa.

This code block was copied/adapted from other similar places but
somehow the comment placement was changed so that it makes less sense.