Fix ALTER TABLE code to update domain constraints when needed.

It's possible for dropping a column, or altering its type, to require
changes in domain CHECK constraint expressions; but the code was
previously only expecting to find dependent table CHECK constraints.
Make the necessary adjustments.

This is a fairly old oversight, but it's a lot easier to encounter
the problem in the context of domains over composite types than it
was before.  Given the lack of field complaints, I'm not going to
bother with a back-patch, though I'd be willing to reconsider that
decision if someone does complain.

Patch by me, reviewed by Michael Paquier

Discussion: https://postgr.es/m/30656.1509128130@sss.pgh.pa.us

doc: Add to hot standby documentation

Document the order of changing certain settings when using hot-standby
servers.  This is just a logical consequence of what was already
documented, but it gives the users some more practical advice.

Author: Yorick Peterse <[email protected]>
Reviewed-by: Aleksander Alekseev <[email protected]>
Reviewed-by: Robert Haas <[email protected]>

pg_basebackup: Fix comparison handling of tablespace mappings on Windows

A candidate path needs to be canonicalized before being checked against
the mappings, because the mappings are also canonicalized.  This is
especially relevant on Windows

Reported-by: nb <[email protected]>
Author: Michael Paquier <[email protected]>
Reviewed-by: Ashutosh Sharma <[email protected]>

Make sure ecpglib does accepts digits behind decimal point even for integers in
Informix mode.

Spotted and fixed by 高增琦 <[email protected]>

Remove inbound links to sql-createuser

CREATE USER is an alias for CREATE ROLE, not its own command any longer,
so clean up references to the 'sql-createuser' link to go to
'sql-createrole' instead.

In passing, change a few cases of 'CREATE USER' to be
'CREATE ROLE ...  LOGIN'.  The remaining cases appear reasonable and
also mention the distinction between 'CREATE ROLE' and 'CREATE USER'.
Also, don't say CREATE USER "assumes" LOGIN, but rather "includes".

Patch-by: David G. Johnston, with assumes->includes by me.
Discussion: https://postgr.es/m/CAKFQuwYrbhKV8hH4TEABrDRBwf=gKremF=mLPQ6X2yGqxgFpYA@mail.gmail.com

Fix underqualified cast-target type names in pg_dump and psql queries.

Queries running with some non-pg_catalog schema frontmost in their search
path need to be careful to schema-qualify type names that should be sought
in pg_catalog.  Vitaly Burovoy reported an oversight of this sort in
pg_dump's dumpSequence, and grepping detected another one in psql's
describeOneTableDetails, both introduced by sequence-related changes in
v10.  In pg_dump, we can fix things by removing the cast altogether, since
it doesn't really matter what data types are reported for these query
result columns.  Likewise in psql, the query seemed to be working unduly
hard to get a result that's guaranteed to be exactly 'bigint'.

I also changed a couple of occurrences of "::char" similarly.  These are
not bugs, since "char" is a typename keyword and not subject to search_path
rules, but it seems better to use uniform style.

Vitaly Burovoy and Tom Lane

Discussion: https://postgr.es/m/CAKOSWN=ds66zLw2SqkLTM8wbXFgDbc_OdkmT3dJfPT2mE5kipA@mail.gmail.com

Don't exaggerate the number of temporary blocks read.

A read that returns zero bytes (or an error) should not increment
the number of temporary blocks read.

Thomas Munro

Discussion: http://postgr.es/m/CAEepm=21xgihg=WaG+O5MFotEZfN6kFETpfw+RkSnEqNQqGn2Q@mail.gmail.com

Fix code related to partitioning schemes for dropped columns.

The entry in appinfo->translated_vars can be NULL; if so, we must avoid
dereferencing it.

Ashutosh Bapat

Discussion: http://postgr.es/m/CAFjFpReL7+1ien=-21rhjpO3bV7aAm1rQ8XgLVk2csFagSzpZQ@mail.gmail.com

Add sanity check for pg_proc.provariadic

Check that the values from pg_proc.h match what ProcedureCreate would
have done.

Robert Haas and Amul Sul

Discussion: http://postgr.es/m/CA+TgmoZ_UGXfq5ygeDDMdUSJ4J_VX7nFnjC6mfY6BgOJ3qZCmw@mail.gmail.com

Doc: call out UPDATE syntax change as a v10 compatibility issue.

The change made by commit 906bfcad7 means that if you're writing
a parenthesized column list in UPDATE ... SET, but that column list
is only one column, you now need to write ROW(expression) on the
righthand side, not just a parenthesized expression.  This was an
intentional change for spec compatibility and potential future
expansion of the possibilities for the RHS, but I'd neglected to
document it as a compatibility issue, figuring that hardly anyone
would bother with parenthesized syntax for a single target column.
I was wrong, as shown by questions from Justin Pryzby, Adam Brusselback,
and others.  Move the release note item into the compatibility section
and point out the behavior change for a single target column.

Discussion: https://postgr.es/m/CAMjNa7cDLzPcs0xnRpkvqmJ6Vb6G3EH8CYGp9ZBjXdpFfTz6dg@mail.gmail.com

Fix autovacuum work item error handling

In autovacuum's "work item" processing, a few strings were allocated in
the current transaction's memory context, which goes away during error
handling; if an error happened during execution of the work item, the
pfree() calls to clean up afterwards would try to release already-released
memory, possibly leading to a crash.  In branch master, this was already
fixed by commit 335f3d04e4c8, so backpatch that to REL_10_STABLE to fix
the problem there too.

As a secondary problem, verify that the autovacuum worker is connected
to the right database for each work item; otherwise some items would be
discarded by workers in other databases.

Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20171014035732[email protected]

Fix typo

Fix typo in comment

Etsuro Fujita

Fix problems with the "role" GUC and parallel query.

Without this fix, dropping a role can sometimes result in parallel
query failures in sessions that have used "SET ROLE" to assume the
dropped role, even if that setting isn't active any more.

Report by Pavan Deolasee.  Patch by Amit Kapila, reviewed by me.

Discussion: http://postgr.es/m/CABOikdOomRcZsLsLK+Z+qENM1zxyaWnAvFh3MJZzZnnKiF+REg@mail.gmail.com

pg_receivewal: Add --no-sync option.

Michael Paquier, reviewed by Kuntal Ghosh and by me.  I did a little
wordsmithing on the documentation, too.

Discussion: http://postgr.es/m/CAB7nPqTuXuyEoVKcWcExh_b0uAjgWd_14KfGLrCTccBZ=VA0KA@mail.gmail.com

Add hash_combine64.

Extracted from a larger patch by Amul Sul, with some comment additions
by me.

Discussion: http://postgr.es/m/20171024113004[email protected]

Support domains over composite types in PL/Perl.

In passing, don't insist on rsi->expectedDesc being set unless we
actually need it; this allows succeeding in a couple of cases where
PL/Perl functions returning setof composite would have failed before,
and makes the error message more apropos in other cases.

Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us

Fix typo.

Eiji Seki

Discussion: http://postgr.es/m/A11BD0E1A40FAC479D740CEFA373E203397E5276@g01jpexmbkw05

Improve comments for parallel executor estimation functions.

The previous comment (which was copied as boilerplate from one file
to the next) implied that it was the executor node itself which was
being serialized, but that's not right.  We're not serializing
the executor nodes; we're just allowing them to store some
additional information in DSM.  Adjusts the comment to reflect this.

Discussion: http://postgr.es/m/CA+TgmoaHVinxG=3h6qBAsyV8xaDyQwbzK7YZnYfE8nJFMK1=FA@mail.gmail.com

Add table_constraint synopsis to ALTER TABLE documentation.

This is already present in the CREATE TABLE documentation, but it's
nicer not to have to refer to CREATE TABLE to find out the syntax
for ALTER TABLE.

Lætitia Avrot

Fix grammar.

Etsuro Fujita

Discussion: http://postgr.es/m/cc7767b6-6a1b-74a2-8b3c-48b8e64c12ed@lab.ntt.co.jp

Fix misplaced ReleaseSysCache call in get_default_partition_oid.

Julien Rouhaud

Discussion: http://postgr.es/m/CAOBaU_Y4omLA+VbsVdA-JwBLoJWiPxfdKCkMjrZM7NMZxa1fKw@mail.gmail.com

Dept of second thoughts: keep aliasp_item in sync with tlistitem.

Commit d5b760ecb wasn't quite right, on second thought: if the
caller didn't ask for column names then it would happily emit
more Vars than if the caller did ask for column names.  This
is surely not a good idea.  Advance the aliasp_item whether or
not we're preparing a colnames list.

Fix crash when columns have been added to the end of a view.

expandRTE() supposed that an RTE_SUBQUERY subquery must have exactly
as many non-junk tlist items as the RTE has column aliases for it.
This was true at the time the code was written, and is still true so
far as parse analysis is concerned --- but when the function is used
during planning, the subquery might have appeared through insertion
of a view that now has more columns than it did when the outer query
was parsed.  This results in a core dump if, for instance, we have
to expand a whole-row Var that references the subquery.

To avoid crashing, we can either stop expanding the RTE when we run
out of aliases, or invent new aliases for the added columns.  While
the latter might be more useful, the former is consistent with what
expandRTE() does for composite-returning functions in the RTE_FUNCTION
case, so it seems like we'd better do it that way.

Per bug #14876 from Samuel Horwitz.  This has been busted since commit
ff1ea2173 allowed views to acquire more columns, so back-patch to all
supported branches.

Discussion: https://postgr.es/m/20171026184035[email protected]

Allow parallel query for prepared statements with generic plans.

This was always intended to work, but due to an oversight in
max_parallel_hazard_walker, it didn't.  In testing, we missed the
fact that it was only working for custom plans, where the parameter
value has been substituted for the parameter itself early enough
that everything worked.  In a generic plan, the Param node survives
and must be treated as parallel-safe.  SerializeParamList provides
for the transmission of parameter values to workers.

Amit Kapila with help from Kuntal Ghosh.  Some changes by me.

Discussion: http://postgr.es/m/CAA4eK1+_BuZrmVCeua5Eqnm4Co9DAXdM5HPAOE2J19ePbR912Q@mail.gmail.com

Rethink the dependencies recorded for FieldSelect/FieldStore nodes.

On closer investigation, commits f3ea3e3e8 et al were a few bricks
shy of a load.  What we need is not so much to lock down the result
type of a FieldSelect, as to lock down the existence of the column
it's trying to extract.  Otherwise, we can break it by dropping that
column.  The dependency on the result type is then held indirectly
through the column, and doesn't need to be recorded explicitly.

Out of paranoia, I left in the code to record a dependency on the
result type, but it's used only if we can't identify the pg_class OID
for the column.  That shouldn't