Per recent discussion on pgsql-hackers, these messages are too
chatty for most users.

We previously recognized that citext wouldn't get marked as collatable
during pg_upgrade from a pre-9.1 installation, and hacked its
create-from-unpackaged script to manually perform the necessary catalog
adjustments.  However, we overlooked the fact that domains over citext,
as well as the citext[] array type, need the same adjustments.  Extend
the script to handle those cases.

Also, the documentation suggested that this was only an issue in pg_upgrade
scenarios, which is quite wrong; loading any dump containing citext from a
pre-9.1 server will also result in the type being wrongly marked.

I approached the documentation problem by changing the 9.1.2 release note
paragraphs about this issue, which is historically inaccurate.  But it
seems better than having the information scattered in multiple places, and
leaving incorrect info in the 9.1.2 notes would be bad anyway.  We'll still
need to mention the issue again in the 9.1.4 notes, but perhaps they can
just reference 9.1.2 for fix instructions.

Per report from Evan Carroll.  Back-patch into 9.1.

If the existing citext type has not merely been created, but used in any
tables, then the upgrade script wasn't doing enough.  We have to update
attcollation for each citext table column, and indcollation for each citext
index column, as well.  Per report from Rudolf van der Leeden.

It's been deprecated for ages according to Tom, and it breaks now given
the previous patch anyway.

Per buildfarm

We have seen one too many reports of people trying to use 9.1 extension
files in the old-fashioned way of sourcing them in psql.  Not only does
that usually not work (due to failure to substitute for MODULE_PATHNAME
and/or @extschema@), but if it did work they'd get a collection of loose
objects not an extension.  To prevent this, insert an \echo ... \quit
line that prints a suitable error message into each extension script file,
and teach commands/extension.c to ignore lines starting with \echo.
That should not only prevent any adverse consequences of loading a script
file the wrong way, but make it crystal clear to users that they need to
do it differently now.

Tom Lane, following an idea of Andrew Dunstan's.  Back-patch into 9.1
... there is not going to be much value in this if we wait till 9.2.

This is an ugly hack to get around the fact that significant parts of the
core backend assume they don't need to worry about passing collation to
equality and hashing functions.  That's true for the core string datatypes,
but citext should ideally have equality behavior that depends on the
specified collation's LC_CTYPE.  However, there's no chance of fixing the
core before 9.2, so we'll have to live with this compromise arrangement for
now.  Per bug #6053 from Regina Obe.

The code changes in this commit should be reverted in full once the core
code is up to speed, but be careful about reverting the docs changes:
I fixed a number of obsolete statements while at it.

Added a new option --extra-install to pg_regress to arrange installing
the respective contrib directory into the temporary installation.
This is currently not yet supported for Windows MSVC builds.

Updated the .gitignore files for contrib modules to ignore the
leftovers of a temp-install check run.

Changed the exit status of "make check" in a pgxs build (which still
does nothing) to 0 from 1.

Added "make check" in contrib to top-level "make check-world".

Although there remains some debate about how CREATE TYPE should represent
the collation property, this doesn't really affect what we need to do in
citext's script, so go ahead and fix that.

It was never terribly consistent to use OR REPLACE (because of the lack of
comparable functionality for data types, operators, etc), and
experimentation shows that it's now positively pernicious in the extension
world.  We really want a failure to occur if there are any conflicts, else
it's unclear what the extension-ownership state of the conflicted object
ought to be.  Most of the time, CREATE EXTENSION will fail anyway because
of conflicts on other object types, but an extension defining only
functions can succeed, with bad results.

This isn't fully tested as yet, in particular I'm not sure that the
"foo--unpackaged--1.0.sql" scripts are OK.  But it's time to get some
buildfarm cycles on it.

sepgsql is not converted to an extension, mainly because it seems to
require a very nonstandard installation process.

Dimitri Fontaine and Tom Lane

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

Also do some further work in the back branches, where quite a bit wasn't
covered by Magnus' original back-patch.

Add bytea.h inclusions as needed.  Some of the contrib regression tests
need to be de-hexified, too.  Per buildfarm.

values being complained of.

In passing, also remove the arbitrary length limitation in the similar
error detail message for foreign key violations.

Itagaki Takahiro

provided by Andrew.

than having some whitespace discrepancy.  Although whitespace is supposed
to be ignored in our regression tests, for some reason buildfarm member
spoonbill doesn't like it.

any negative or positive number, not just -1 or 1. Fix comment on
varstr_cmp and citext test case accordingly.

As pointed out by Zdenek Kotala, and buildfarm member gothic moth.

citext-to-and-from-xml tests, since those caused variation between
installations with or without libxml without really proving much.  Instead
repurpose citext_1.out as the expected results in glibc en_US (and probably
other) locales.

pointers.  This is only a whitespace change, which ought to be ignored
by regression testing, but for some reason buildfarm member spoonbill
doesn't like it.

David Wheeler

of the STRING type category, thereby opening up the mechanism for user-defined
types.  This is mainly for the benefit of citext, though; there aren't likely
to be a lot of types that are all general-purpose character strings.
Per discussion with David Wheeler.

by putting it into the standard string category, we cause casts from citext
to text to be recognized as "preferred" casts.  This eliminates the need
for creation of alias functions and operators that only serve to prevent
ambiguous-function errors; get rid of the ones that were in the original
commit.

David E. Wheeler