Add functions min_scale(numeric) and trim_scale(numeric).

These allow better control of trailing zeroes in numeric values.

Pavel Stehule, based on an old proposal of Marko Tiikkaja's;
review by Karl Pinc

Discussion: https://postgr.es/m/CAFj8pRDjs-navGASeF0Wk74N36YGFJ+v=Ok9_knRa7vDc-qugg@mail.gmail.com

Have logical replication subscriber fire column triggers

The logical replication apply worker did not fire per-column update
triggers because the updatedCols bitmap in the RTE was not populated.
This fixes that.

Reviewed-by: Euler Taveira <euler@timbira.com.br>
Discussion: https://www.postgresql.org/message-id/flat/21673e2d-597c-6afe-637e-e8b10425b240%402ndquadrant.com

Remove support for OpenSSL 0.9.8 and 1.0.0

Support is out of scope from all the major vendors for these versions
(for example RHEL5 uses a version based on 0.9.8, and RHEL6 uses 1.0.1),
and it created some extra maintenance work.  Upstream has stopped
support of 0.9.8 in December 2015 and of 1.0.0 in February 2016.

Since b1abfec, note that the default SSL protocol version set with
ssl_min_protocol_version is TLSv1.2, whose support was added in OpenSSL
1.0.1, so there is no point to enforce ssl_min_protocol_version to TLSv1
in the SSL tests.

Author: Michael Paquier
Reviewed-by: Daniel Gustafsson, Tom Lane
Discussion: https://postgr.es/m/20191205083252.GE5064@paquier.xyz

Remove redundant incomplete split assertion.

The fastpath insert optimization's incomplete split flag Assert() is
redundant.  We'll reach the more general Assert() within
_bt_findinsertloc() in all cases. (Besides, Assert()'ing that the
rightmost page doesn't have the flag set never made much sense.)

Minor style improvements for tab-completion test.

Use qr// syntax for regex values.
Include the regex that failed to match in diagnostic reports.

Dagfinn Ilmari Mannsåker

Discussion: https://postgr.es/m/87k16610xk.fsf@wibble.ilmari.org

Docs: use more standard terminology "round-to-nearest-even" instead of "round-to-even".

Per suggestion from Tom Lane.
Discussion: https://postgr.es/m/flat/20191230.093451.1762483750956466101.t-ishii%40sraoss.co.jp

Avoid reading ~/.inputrc in tab-completion test, and revert other changes.

The true explanation for Peter Geoghegan's trouble report turns out
to be that he has a ~/.inputrc that affects readline's behavior
enough to break this test.  Prevent readline from reading that file.

Also, the best way to prevent TERM from affecting the results seems
to be to unset it altogether, not to set it to "xterm".  The latter
choice licenses readline to emit xterm escape sequences, and there's
a lot of variation in exactly what it will emit.

Revert changes that attempted to account exactly for xterm escape
sequences.  We shouldn't need that with TERM unset, and it was not
looking like a maintainable solution anyway.

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

Don't try to force TERM to a fixed value in tab-completion test.

Right at the moment, this is making things worse not better in the
buildfarm.  I'm not happy with anything about the current state,
but let's at least try to have a green buildfarm report while further
investigation continues.

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

In tab-completion test, print out the value of TERM before changing it.

I'm curious to see what values are prevailing in the buildfarm.

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

Skip memcpy(x, x) in qunique().

It has undefined behavior.  Follow the precedent of commit
9a9473f3cce1a21c25d6cc7569710e832d2b180b.  No back-patch, since the
master branch alone has this function.

Discussion: https://postgr.es/m/20191229070221.GA13873@gust.leadboat.com

Make tab-completion tests more robust.

Depending on as-yet-incompletely-explained factors, readline/libedit
might choose to emit screen-control escape sequences as part of
repainting the display.  I'd tried to make the test patterns avoid
matching parts of the output that are likely to contain such, but
it seems that there's really no way around matching them explicitly
in some places, unless we want to just give up testing some behaviors
such as display of alternatives.

Per report from Peter Geoghegan.

Discussion: https://postgr.es/m/CAH2-WznPzfWHu8PQwv1Qjpf4wQVPaaWpoO5NunFz9zsYKB4uJA@mail.gmail.com

Make better use of ParseState in ProcessUtility

Pass ParseState into the functions called from
standard_ProcessUtility() instead passing the query string and query
environment separately.  No functionality change, but it makes the
notation consistent.  We had already started moving things into
that direction piece by piece, and this completes it.

Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/6e7aa4a1-be6a-1a75-b1f9-83a678e5184a@2ndquadrant.com

Add xl_btree_delete optimization.

Commit 558a9165e08 taught _bt_delitems_delete() to produce its own XID
horizon on the primary.  Standbys no longer needed to generate their own
latestRemovedXid, since they could just use the explicitly logged value
from the primary instead.  The deleted offset numbers array from the
xl_btree_delete WAL record was no longer used by the REDO routine for
anything other than deleting the items.

This enables a minor optimization:  We now treat the array as buffer
state, not generic WAL data, following _bt_delitems_vacuum()'s example.
This should be a minor win, since it allows us to avoid including the
deleted items array in cases where XLogInsert() stores the whole buffer
anyway.  The primary goal here is to make the code more maintainable,
though.  Removing inessential differences between the two functions
highlights the fundamental differences that remain.

Also change xl_btree_delete to use uint32 for the size of the array of
item offsets being deleted.  This brings xl_btree_delete closer to
xl_btree_vacuum.  Furthermore, it seems like a good idea to use an
explicit-width integer type (the field was previously an "int").

Bump XLOG_PAGE_MAGIC because xl_btree_delete changed.

Discussion: https://postgr.es/m/CAH2-Wzkz4TjmezzfAbaV1zYrh=fr0bCpzuJTvBe5iUQ3aUPsCQ@mail.gmail.com

Further fixes for tab-completion TAP tests.

Escape non-printable characters in failure reports, by using Data::Dumper
in Useqq mode.  Also, bump $Test::Builder::Level so the diagnostic
references the calling line, and use diag() instad of note(),
so it shows even in non-verbose mode (per request from Christoph Berg).

Also, give up on trying to test for the specific way that readline
chooses to overwrite existing text in the \DRD -> \drds test.
There are too many variants, it seems, at least on the libedit
side of things.

Dagfinn Ilmari Mannsåker and Tom Lane

Discussion: https://postgr.es/m/20200103110128.GA28967@msg.df7cb.de

Add an ugly workaround for a bug in some recent libedit versions.

Debian unstable is shipping a broken version of libedit: it de-escapes
words before passing them to the application's tab completion function,
preventing us from recognizing backslash commands.  Fortunately,
we have enough information available to dig the original text out of
rl_line_buffer, so ignore the string argument and do that.

I view this as a temporary workaround to get the affected buildfarm
members back to green in the wake of 7c015045b.  I hope we can get
rid of it once somebody fixes Debian's libedit; hence, no back-patch,
at least for now.

Discussion: https://postgr.es/m/20200103110128.GA28967@msg.df7cb.de

pgbench: Improve test description

Author: Fabien COELHO <coelho@cri.ensmp.fr>

Fix typos in parallel query docs.

Reported-by: Jon Jensen
Author: Jon Jensen
Reviewed-by: Amit Kapila and Robert Haas
Backpatch-through: 10
Discussion: https://postgr.es/m/nycvar.YSQ.7.76.1912301807510.9899@ybpnyubfg

Clear up btree_xlog_split() alignment comment.

Adjust a comment that describes how alignment of the new left page high
key works in btree_xlog_split(), the nbtree page split REDO routine.
The wording used before commit 2c03216d831 is much clearer, so go back
to that.

Minor portability fixes for new TAP script.

Satisfy perlcritic, mostly.  Per buildfarm.

Correct _bt_delitems_vacuum() lock comments.

The expectation within _bt_delitems_vacuum() is that caller has a
super-exclusive/cleanup buffer lock (not just a pin and a write lock).

Fix cloning of row triggers to sub-partitions

When row triggers exist in partitioned partitions that are not either
part of FKs or deferred unique constraints, they are not correctly
cloned to their partitions.  That's because they are marked "internal",
and those are purposefully skipped when doing the clone triggers dance.
Fix by relaxing the condition on which internal triggers are skipped.

Amit Langote initially diagnosed the problem and proposed a fix, but I
used a different approach.

Reported-by: Petr Fedorov
Discussion: https://postgr.es/m/6b3f0646-ba8c-b3a9-c62d-1c6651a1920f@phystech.edu

Add basic TAP tests for psql's tab-completion logic.

Up to now, psql's tab-complete.c has had exactly no regression test
coverage.  This patch is an experimental attempt to add some.

This needs Perl's IO::Pty module, which isn't installed everywhere,
so the test script just skips all tests if that's not present.
There may be other portability gotchas too, so I await buildfarm
results with interest.

So far this just covers a few very basic keyword-completion and
query-driven-completion scenarios, which should be enough to let us
get a feel for whether this is practical at all from a portability
standpoint.  If it is, there's lots more that can be done.

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

Fix typmod exposed for scalar function in FROM, too.

On further reflection about commit 4d02eb017, it occurs to me that
expandRTE() had better agree with what addRangeTableEntryForFunction()
is doing.  So teach that about functions possibly having typmods, too.

Reorder two nbtree.h function prototypes.

Make the function prototype order consistent with the definition order
in nbtpage.c.

Fix collation exposed for scalar function in FROM.

One code path in addRangeTableEntryForFunction() neglected to assign
a collation to the tupdesc entry it constructs (which is a bit odd
considering the other path did do so).  This didn't matter before commit
5815696bc, because nothing would look at the type data in this tupdesc;
but now it does.

While at it, make sure we assign the correct typmod as well.  Most
function expressions don't have a determinate typmod, but some do.

Per buildfarm, which showed failures in non-C collations, a case
I'd not thought to test for this patch :-(

Make parser rely more heavily on the ParseNamespaceItem data structure.

When I added the ParseNamespaceItem data structure (in commit 5ebaaa494),
it wasn't very tightly integrated into the parser's APIs.  In the wake of
adding p_rtindex to that struct (commit b541e9acc), there is a good reason
to make more use of it: by passing around ParseNamespaceItem pointers
instead of bare RTE pointers, we can get rid of various messy methods for
passing back or deducing the rangetable index of an RTE during parsing.
Hence, refactor the addRangeTableEntryXXX functions to build and return
a ParseNamespaceItem struct, not just the RTE proper; and replace
addRTEtoQuery with addNSItemToQuery, which is passed a ParseNamespaceItem
rather than building one internally.

Also, add per-column data (a ParseNamespaceColumn array) to each
ParseNamespaceItem.  These arrays are built during addRangeTableEntryXXX,
where we have column type data at hand so that it's nearly free to fill
the data structure.  Later, when we need to build Vars referencing RTEs,
we can use the ParseNamespaceColumn info to avoid the rather expensive
operations done in get_rte_attribute_type() or expandRTE().
get_rte_attribute_type() is indeed dead code now, so I've removed it.
This makes for a useful improvement in parse analysis speed, around 20%
in one moderately-complex test query.

The ParseNamespaceColumn structs also include Var identity information
(varno/varattno).  That info isn't actually being used in this patch,
except that p_varno == 0 is a handy test for a dropped column.
A follow-on patch will make more use of it.

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

Fix comment in test

The comment was apparently copy-and-pasted and did not reflect the
actual test outcome.

Fix running out of file descriptors for spill files.

Currently while decoding changes, if the number of changes exceeds a
certain threshold, we spill those to disk.  And this happens for each
(sub)transaction.  Now, while reading all these files, we don't close them
until we read all the files.  While reading these files, if the number of
such files exceeds the maximum number of file descriptors, the operation
errors out.

Use PathNameOpenFile interface to open these files as that internally has
the mechanism to release kernel FDs as needed to get us under the
max_safe_fds limit.

Reported-by: Amit Khandekar
Author: Amit Khandekar
Reviewed-by: Amit Kapila
Backpatch-through: 9.4
Discussion: https://postgr.es/m/CAJ3gD9c-sECEn79zXw4yBnBdOttacoE-6gAyP0oy60nfs_sabQ@mail.gmail.com

Revise BTP_HAS_GARBAGE nbtree VACUUM comments.

_bt_delitems_vacuum() comments claimed that it isn't worth another scan
of the page to avoid falsely unsetting the BTP_HAS_GARBAGE page flag
hint (this happens to be the same wording that was removed from
_bt_delitems_delete() by my recent commit fe97c61c).  The comments made
little sense, though.  The issue can't have much to do with performing a
second scan of the target leaf page, since an LP_DEAD test could easily
be performed in the first scan of the page anyway (the scan that takes
place in btvacuumpage() caller).

Revise the explanation.  It makes much more sense to frame this as an
issue about recovery conflicts.  _bt_delitems_vacuum() cannot easily
generate an XID cutoff in the same way that _bt_delitems_delete() is
designed to.

Falsely unsetting the page flag is not ideal, and is likely to happen
more often than was supposed by the original comments.  Explain why it
usually isn't a problem in practice.  There may be an argument for
_bt_delitems_vacuum() not clearing the BTP_HAS_GARBAGE bit, removing the
question of it being falsely unset by VACUUM (there may even be an
argument for not using a page level hint at all).  This can be revisited
later.

Test GROUP BY matching of join columns that are type-coerced by USING.

If we have, say, an int column that is left-joined to a bigint column
with USING, the merged column is the int column promoted to bigint.
GROUP BY's tests for whether grouping on the merged column allows a
reference to the underlying column, or vice versa, should know about
that relationship --- and they do.  But I nearly broke this case with
an ill-advised optimization, so the lack of any test coverage for it
seems like a bad idea.

Update btree_xlog_delete() comments.

Commit fe97c61c updated LP_DEAD item deletion comments, but missed a
minor discrepancy on the REDO side.  Fix it now.

In passing, don't talk about the btree_xlog_vacuum() behavior within
btree_xlog_delete().  The reliance on XLOG_HEAP2_CLEANUP_INFO records
for recovery conflicts is already discussed within btvacuumpage() and
mentioned again in passing above btree_xlog_vacuum(), which seems
sufficient.

Update copyrights for 2020

Backpatch-through: update all files in master, backpatch legal files through 9.4

Modernize Python exception syntax in documentation

Change the exception syntax used in the documentation to use the more
current

    except Exception as ex:

rather than the old

    except Exception, ex:

We keep the old syntax in the test code since Python <2.6 is still
supported there, but the documentation might as well use the modern
syntax.

Micro-optimize AllocSetFreeIndex() by reference to pg_bitutils code.

Use __builtin_clz() where available.  Where it isn't, we can still win
a little by using the pg_leftmost_one_pos[] lookup table instead of
having a private table.

Also drop the initial right shift by ALLOC_MINBITS in favor of
subtracting ALLOC_MINBITS from the leftmost-one-pos result.  This
is a win because the compiler can fold that adjustment into other
constants it'd have to add anyway, making the shift-removal free.

Also, we can explain this coding as an unrolled form of
pg_leftmost_one_pos32(), even though that's a bit ahistorical
since it long predates pg_bitutils.h.

John Naylor, with some cosmetic adjustments by me

Discussion: https://postgr.es/m/CACPNZCuNUGMxjK7WTn_=WZnRbfASDdBxmjsVf2+m9MdmeNw_sg@mail.gmail.com

Add pg_dump test for triggers on partitioned tables

This currently works, but add this test to ensure it continues to work.
Lack of this test became evident after a recent bugfix submission that
would have inadvertently broken it, in
https://postgr.es/m/CA+HiwqFM2=i+uHB9o4OkLbE2S3sjPHoVe2wXuAD1GLJ4+Pk9eg@mail.gmail.com

doc:  add examples of creative use of unique expression indexes

Unique expression indexes can constrain data in creative ways, so show
two examples.

Reported-by: Tuomas Leikola
Discussion: https://postgr.es/m/156760275564.1127.12321702656456074572@wrigleys.postgresql.org

Backpatch-through: 9.4

docs:  clarify infinite range values from data-type infinities

The previous docs referenced these distinct ideas confusingly.

Reported-by: Eugen Konkov
Discussion: https://postgr.es/m/376945611.20191026161529@yandex.ru

Backpatch-through: 9.4

Forbid DROP SCHEMA on temporary namespaces

This operation was possible for the owner of the schema or a superuser.
Down to 9.4, doing this operation would cause inconsistencies in a
session whose temporary schema was dropped, particularly if trying to
create new temporary objects after the drop.  A more annoying
consequence is a crash of autovacuum on an assertion failure when
logging information about an orphaned temp table dropped.  Note that
because of 246a6c8 (present in v11~), which has made the removal of
orphaned temporary tables more aggressive, the failure could be
triggered more easily, but it is possible to reproduce down to 9.4.

Reported-by: Mahendra Singh, Prabhat Sahu
Author: Michael Paquier
Reviewed-by: Kyotaro Horiguchi, Mahendra Singh
Discussion: https://postgr.es/m/CAKYtNAr9Zq=1-ww4etHo-VCC-k120YxZy5OS01VkaLPaDbv2tg@mail.gmail.com
Backpatch-through: 9.4

Revert "Rename files and headers related to index AM"

This follows multiple complains from Peter Geoghegan, Andres Freund and
Alvaro Herrera that this issue ought to be dug more before actually
happening, if it happens.

Discussion: https://postgr.es/m/20191226144606.GA5659@alvherre.pgsql

Fix possible loss of sync between rectypeid and underlying PLpgSQL_type.

When revalidate_rectypeid() acts to update a stale record type OID
in plpgsql's data structures, it fixes the active PLpgSQL_rec struct
as well as the PLpgSQL_type struct it references.  However, the latter
is shared across function executions while the former is not.  In a
later function execution, the PLpgSQL_rec struct would be reinitialized
by copy_plpgsql_datums and would then contain a stale type OID,
typically leading to "could not open relation with OID NNNN" errors.
revalidate_rectypeid() can easily fix this, fortunately, just by
treating typ->typoid as authoritative.

Per report and diagnosis from Ashutosh Sharma, though this is not his
suggested fix.  Back-patch to v11 where this code came in.

Discussion: https://postgr.es/m/CAE9k0Pkd4dZwt9J5pS9xhJFWpUtqs05C9xk_GEwPzYdV=GxwWg@mail.gmail.com

Improve comments in utils/rel.h.

Mark the fields that should be accessed via partitioning-related
functions, as we already did for some other fields.

Amit Langote

Discussion: https://postgr.es/m/CA+HiwqFnK6LbVMACMCaqwWrvoSFTecZzufKRahg2qGvLPYMX=g@mail.gmail.com

Refactor parser's generation of Var nodes.

Instead of passing around a pointer to the RangeTblEntry that
provides the desired column, pass a pointer to the associated
ParseNamespaceItem.  The RTE is trivially reachable from the nsitem,
and having the ParseNamespaceItem allows access to additional
information.  As proof of concept for that, add the rangetable index
to ParseNamespaceItem, and use that to get rid of RTERangeTablePosn
searches.

(I have in mind to teach the parser to generate some different
representation for Vars that are nullable by outer joins, and
keeping the necessary information in ParseNamespaceItems seems
like a reasonable approach to that.  But whether that ever
happens or not, this seems like good cleanup.)

Also refactor the code around scanRTEForColumn so that the
"fuzzy match" stuff does not leak out of parse_relation.c.

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

Fix some comments related to logical repslot advancing

confirmed_flush is part of a replication slot's information, but not
confirmed_lsn.

Author: Kyotaro Horiguchi
Discussion: https://postgr.es/m/20191226.175919.17237335658671970.horikyota.ntt@gmail.com
Backpatch-through: 11

Refactor code dedicated to index vacuuming in vacuumlazy.c

The part in charge of doing the vacuum on all the indexes of a relation
was duplicated, with the same handling for progress reporting done.
While on it, update the progress reporting for heap vacuuming in the
subroutine doing the actual work, keeping the status update local.  This
way, any future caller of lazy_vacuum_heap() does not have to worry
about doing any progress reporting update.

Author: Justin Pryzby, Michael Paquier
Discussion: https://postgr.es/m/20191120210600.GC30362@telsasoft.com

Add note about how each partition's default value is treated, into the doc.

Column defaults may be specified separately for each partition.
But INSERT via a partitioned table ignores those partition's default values.
The former is documented, but the latter rest