In libecpg do not set an sqlda field that is 'reserved for future use' unless
we know what should be stored in there.

Normalize whitespace in the arguments of <indexterm>

Strip leading and trailing whitespace and replace interior whitespace
by a single space.  This avoids problems with the index generator
producing duplicate index entries for terms that differ only in
whitespace.

Commit dca30da3433c40b5f92f1704c496cda052decef9 actually fixed all the
indexterm elements that would cause this problem at the moment, but in
case it sneaks in again, we're set.

Improve cost estimation for aggregates and window functions.

The previous coding failed to account properly for the costs of evaluating
the input expressions of aggregates and window functions, as seen in a
recent gripe from Claudio Freire.  (I said at the time that it wasn't
counting these costs at all; but on closer inspection, it was effectively
charging these costs once per output tuple.  That is completely wrong for
aggregates, and not exactly right for window functions either.)

There was also a hard-wired assumption that aggregates and window functions
had procost 1.0, which is now fixed to respect the actual cataloged costs.

The costing of WindowAgg is still pretty bogus, since it doesn't try to
estimate the effects of spilling data to disk, but that seems like a
separate issue.

In pg_upgrade, only compile copy_file() on non-Win32 systems.

Per report from Andrew Dunstan.

Improve findoidjoins to cover more cases.

Teach the program and script to deal with OID-array referencing columns,
which we now have several of.  Also, modify the recommended usage process
to specify that the program should be run against the regression database
rather than template1.  This lets it find numerous joins that cannot be
found in template1 because the relevant catalogs are entirely empty.

Together these changes add seventeen formerly-missed cases to the oidjoins
regression test.

Silence a few compiler warnings from gcc on MinGW.

Most of these cast DWORD to int or unsigned int for printf type handling.
This is safe even on 64 bit architectures because a DWORD is always 32 bits.

In one case a variable is initialised to keep the compiler happy.

Update oidjoins regression test for 9.1 catalog schema additions.

Hash indexes had better pass the index collation to support functions, too.

Per experimentation with contrib/citext, whose hash function assumes that
it'll be passed a collation.

Adjust comments about collate.linux.utf8 regression test.

This test should now work in any database with UTF8 encoding, regardless
of the database's default locale.  The former restriction was really
"doesn't work if default locale is C", and that was because of not handling
mbstowcs/wcstombs correctly.

Fix char2wchar/wchar2char to support collations properly.

These functions should take a pg_locale_t, not a collation OID, and should
call mbstowcs_l/wcstombs_l where available.  Where those functions are not
available, temporarily select the correct locale with uselocale().

This change removes the bogus assumption that all locales selectable in
a given database have the same wide-character conversion method; in
particular, the collate.linux.utf8 regression test now passes with
LC_CTYPE=C, so long as the database encoding is UTF8.

I decided to move the char2wchar/wchar2char functions out of mbutils.c and
into pg_locale.c, because they work on wchar_t not pg_wchar_t and thus
don't really belong with the mbutils.c functions.  Keeping them where they
were would have required importing pg_locale_t into pg_wchar.h somehow,
which did not seem like a good plan.

Fix contrib/btree_gist to handle collations properly.

Make use of the collation attached to the index column, instead of
hard-wiring DEFAULT_COLLATION_OID.  (Note: in theory this could require
reindexing btree_gist indexes on textual columns, but I rather doubt anyone
has one with a non-default declared collation as yet.)

Make GIN and GIST pass the index collation to all their support functions.

Experimentation with contrib/btree_gist shows that the majority of the GIST
support functions potentially need collation information.  Safest policy
seems to be to pass it to all of them, instead of making assumptions about
which ones could possibly need it.

De-kludge contrib/btree_gin for collations.

Using DEFAULT_COLLATION_OID in the comparePartial functions was not only
a lame hack, but outright wrong, because the compare functions for
collation-aware types were already responding to the declared index
collation.  So comparePartial would have the wrong expectation about
the index's sort order, possibly leading to missing matches for prefix
searches.

Small update to emacs example configuration

Since both tarballs and git now result in a "postgresql" directory
rather than a "pgsql" directory, adjust the example configuration to
look for the former.

Add fill-column setting to emacs example configurations

This matches the maximum line length that pgindent uses.

Make a code-cleanup pass over the collations patch.

This patch is almost entirely cosmetic --- mostly cleaning up a lot of
neglected comments, and fixing code layout problems in places where the
patch made lines too long and then pgindent did weird things with that.
I did find a bug-of-omission in equalTupleDescs().

Improve doc wording for SQL syntax of LIMIT/OFFSET.

Avoid possible divide-by-zero in gincostestimate.

Per report from Jeff Janes.

Allow ALTER TYPE .. ADD ATTRIBUTE .. CASCADE to recurse to descendants.

Without this, adding an attribute to a typed table with an inheritance
child fails, which is surprising.

Noah Misch, with minor changes by me.

Fix use of incorrect constant RemoveRoleFromObjectACL.

This could cause failures when DROP OWNED BY attempt to remove default
privileges on sequences.  Back-patching to 9.0.

Shigeru Hanada

Typo fix.

Allow ALTER TABLE name {OF type | NOT OF}.

This syntax allows a standalone table to be made into a typed table,
or a typed table to be made standalone.  This is possibly a mildly
useful feature in its own right, but the real motivation for this
change is that we need it to make pg_upgrade work with typed tables.
This doesn't actually fix that problem, but it's necessary
infrastructure.

Noah Misch

Fix bugs in indexing of in-doubt HOT-updated tuples.

If we find a DELETE_IN_PROGRESS HOT-updated tuple, it is impossible to know
whether to index it or not except by waiting to see if the deleting
transaction commits.  If it doesn't, the tuple might again be LIVE, meaning
we have to index it.  So wait and recheck in that case.

Also, we must not rely on ii_BrokenHotChain to decide that it's possible to
omit tuples from the index.  That could result in omitting tuples that we
need, particularly in view of yesterday's fixes to not necessarily set
indcheckxmin (but it's broken even without that, as per my analysis today).
Since this is just an extremely marginal performance optimization, dropping
the test shouldn't hurt.

These cases are only expected to happen in system catalogs (they're
possible there due to early release of RowExclusiveLock in most
catalog-update code paths).  Since reindexing of a system catalog isn't a
particularly performance-critical operation anyway, there's no real need to
be concerned about possible performance degradation from these changes.

The worst aspects of this bug were introduced in 9.0 --- 8.x will always
wait out a DELETE_IN_PROGRESS tuple.  But I think dropping index entries
on the strength of ii_BrokenHotChain is dangerous even without that, so
back-patch removal of that optimization to 8.3 and 8.4.

Set indcheckxmin true when REINDEX fixes an invalid or not-ready index.

Per comment from Greg Stark, it's less clear that HOT chains don't conflict
with the index than it would be for a valid index.  So, let's preserve the
former behavior that indcheckxmin does get set when there are
potentially-broken HOT chains in this case.  This change does not cause any
pg_index update that wouldn't have happened anyway, so we're not
re-introducing the previous bug with pg_index updates, and surely the case
is not significant from a performance standpoint; so let's be as
conservative as possible.

Make plan_cluster_use_sort cope with no IndexOptInfo for the target index.

The original coding assumed that such a case represents caller error, but
actually get_relation_info will omit generating an IndexOptInfo for any
index it thinks is unsafe to use.  Therefore, handle this case by returning
"true" to indicate that a seqscan-and-sort is the preferred way to
implement the CLUSTER operation.  New bug in 9.1, no backpatch needed.
Per bug #5985 from Daniel Grace.

Fix PL/Python traceback for error in separate file

It assumed that the lineno from the traceback always refers to the
PL/Python function.  If you created a PL/Python function that imports
some code, runs it, and that code raises an exception, PLy_traceback
would get utterly confused.

Now we look at the file name reported with the traceback and only
print the source line if it came from the PL/Python function.

Jan Urbański

Pg_upgrade C comment addition.

Document why we do the missing new database check during the check
phase.

Quotes in strings injected into bki file need to escaped. In particular,
"People's Republic of China" locale on Windows was causing initdb to fail.

This fixes bug #5818 reported by yulei. On master, this makes the mapping
of "People's Republic of China" to just "China" obsolete. In 9.0 and 8.4,
just fix the escaping. Earlier versions didn't have locale names in bki
file.

Throw error for mismatched pg_upgrade clusters

If someone removes the 'postgres' database from the old cluster and the
new cluster has a 'postgres' database, the number of databases will not
match.  We actually could upgrade such a setup, but it would violate the
1-to-1 mapping of database counts, so we throw an error instead.

Previously they got an error during the upgrade, and not at the check
stage; PG 9.0.4 does the same.

Add C comment

Add C comment about why we throw an error if the pg_upgrade old/new
database counts don't match.

Avoid changing an index's indcheckxmin horizon during REINDEX.

There can never be a need to push the indcheckxmin horizon forward, since
any HOT chains that are actually broken with respect to the index must
pre-date its original creation.  So we can just avoid changing pg_index
altogether during a REINDEX operation.

This offers a cleaner solution than my previous patch for the problem
found a few days ago that we mustn't try to update pg_index while we are
reindexing it.  System catalog indexes will always be created with
indcheckxmin = false during initdb, and with this modified code we should
never try to change their pg_index entries.  This avoids special-casing
system catalogs as the former patch did, and should provide a performance
benefit for many cases where REINDEX formerly caused an index to be
considered unusable for a short time.

Back-patch to 8.3 to cover all versions containing HOT.  Note that this
patch changes the API for index_build(), but I believe it is unlikely that
any add-on code is calling that directly.

Revert "Prevent incorrect updates of pg_index while reindexing pg_index itself."

This reverts commit 4b6106ccfea21e86943f881edcf3cfc03661a415 of 2011-04-15.
There's a better way to do it, which will follow shortly.

Refix the unaccent regression test on MSVC properly

... for some value of "properly".  Instead of overriding REGRESS_OPTS,
set the variables ENCODING and NO_LOCALE, which is more expressive and
allows overriding by the user.  Fix vcregress.pl to handle that.

Treat config.pl as optional in vcregress.pl

This is how build.pl treats it and how it's documented.

Fix typo

Add gitignore entries for Windows MSVC builds

Avoid unused variable warnings for certain configurations

Refrain from canonicalizing a client_encoding setting of "UNICODE".

While "UTF8" is the correct name for this encoding, existing JDBC drivers
expect that if they send "UNICODE" it will read back the same way; they
fail with an opaque "Protocol error" complaint if not.  This will be fixed
in the 9.1 drivers, but until older drivers are no longer in use in the
wild, we'd better leave "UNICODE" alone.  Continue to canonicalize all
other inputs.  Per report from Steve Singer and subsequent discussion.

Silence compiler warning about casting HANDLE to long on WIN64.

Silence compiler warning about unused variable on Windows.

Fix handling of collations in multi-row VALUES constructs.

Per spec we ought to apply select_common_collation() across the expressions
in each column of the VALUES table.  The original coding was just taking
the first row and assuming it was representative.

This patch adds a field to struct RangeTblEntry to carry the resolved
collations, so initdb is forced for changes in stored rule representation.

Only allow typed tables to hang off composite types, not e.g. tables.

This also ensures that we take a relation lock on the composite type when
creating a typed table, which is necessary to prevent the composite type
and the typed table from getting out of step in the face of concurrent
DDL.

Noah Misch, with some changes.

Attempt to remedy buildfarm breakage caused by commit f536d4194.

recoveryStopsHere() must check the resource manager ID.

Before commit c016ce728139be95bb0dc7c4e5640507334c2339, this wasn't
needed, but now that multiple resource manager IDs can percolate down
through here, we have to make sure we know which one we've got.
Otherwise, we can confuse (for example) an XLOG_XACT_COMMIT record
with an XLOG_CHECKPOINT_SHUTDOWN record.

Review by Jaime Casanova

Fix assorted infelicities in collation handling in psql's describe.c.

In \d, be more careful to print collation only if it's not the default for
the column's data type.  Avoid assuming that the name "default" is magic.

Fix \d on a composite type so that it will print per-column collations.
It's no longer the case that a composite type cannot have modifiers.
(In consequence, the expected outputs for composite-type regression tests
change.)

Fix \dD so that it will print collation for a domain, again only if it's
not the same as the base type's collation.

Document COLLATE option in CREATE TYPE reference page.

Curiously, it was already documented in ALTER TYPE ADD ATTRIBUTE, but
not here.

Fix pg_dump to handle collations applied to columns of composite types.

CREATE TYPE and ALTER TYPE ADD ATTRIBUTE handle this, so I suppose it's
an intended feature, but pg_dump didn't know about it.

Add check for matching column collations in ALTER TABLE ... INHERIT.

The other DDL operations that create an inheritance relationship were
checking for collation match already, but this one got missed.

Also fix comments that failed to mention collation checks.

Support a COLLATE clause in plpgsql variable declarations.

This allows the usual rules for assigning a collation to a local variable
to be overridden.  Per discussion, it seems appropriate to support this
rather than forcing all local variables to have the argument-derived
collation.

foreach() and list_delete() don't mix.

Fix crash when releasing duplicate entries in the encoding conversion cache
list, caused by releasing the current entry of the list being chased by
foreach().  We have a standard idiom for handling such cases, but this
loop wasn't using it.

This got broken in my recent rewrite of GUC assign hooks.  Not sure how
I missed this when testing the modified code, but I did.  Per report from
Peter.

Add an Assert that indexam.c isn't used on an index awaiting reindexing.

This might have caught the recent embarrassment over trying to modify
pg_index while its indexes were being rebuilt.

Noah Misch

Simplify reindex_relation's API.

For what seem entirely historical reasons, a bitmask "flags" argument was
recently added to reindex_relation without subsuming its existing boolean
argument into that bitmask.  This seems a bit bizarre, so fold them
together.

Clean up collation processing in prepunion.c.

This area was a few bricks shy of a load, and badly under-commented too.
We have to ensure that the generated targetlist entries for a set-operation
node expose the correct collation for each entry, since higher-level
processing expects the tlist to reflect the true ordering of the plan's
output.

This hackery wouldn't be necessary if SortGroupClause carried collation
info ... but making it do so would inject more pain in the parser than
would be saved here.  Still, we might want to rethink that sometime.

Set client encoding explicitly in plpython_unicode test

This will (hopefully) eliminate the need for the
plpython_unicode_0.out expected file.

Prevent incorrect updates of pg_index while reindexing pg_index itself.

The places that attempt to change pg_index.indcheckxmin during a reindexing
operation cannot be executed safely if pg_index itself is the subject of
the operation.  This is the explanation for a couple of recent reports of
VACUUM FULL failing with
ERROR:  duplicate key value violates unique constraint "pg_index_indexrelid_index"
DETAIL:  Key (indexrelid)=(2678) already exists.

However, there isn't any real need to update indcheckxmin in such a
situation, if we assume that pg_index can never contain a truly broken HOT
chain.  This assumption holds if new indexes are never created on it during
concurrent operations, which is something we don't consider safe for any
system catalog, not just pg_index.  Accordingly, modify the code to not
manipulate indcheckxmin when reindexing any system catalog.

Back-patch to 8.3, where HOT was introduced.  The known failure scenarios
involve 9.0-style VACUUM FULL, so there might not be any real risk before
9.0, but let's not assume that.

Suppress unused-function warning on non-WIN32 builds.

Guard against incoming rowcount estimate of NaN in cost_mergejoin().

Although rowcount estimates really ought not be NaN, a bug elsewhere
could perhaps result in that, and that would cause Assert failure in
cost_mergejoin, which I believe to be the explanation for bug #5977 from
Anton Kuznetsov.  Seems like a good idea to expend a couple more cycles
to prevent that, even though the real bug is elsewhere.  Not back-patching,
though, because we don't encourage running production systems with
Asserts on.

setlocale() on Windows doesn't work correctly if the locale name contains
apostrophes or dots. There isn't much hope of Microsoft fixing it any time
soon, it's been like that for ages, so we better work around it. So, map a
few common Windows locale names known to cause problems to aliases that work.

On Windows, if the encoding implied by locale is not allowed as a
server-encoding, fall back to UTF-8. It happens at least with the Chinese
locale, which implies BIG5. This is safe, because on Windows all locales
are compatible with UTF-8.

Note that Bison on GnuWin32 has trouble with paths with spaces

Peter Eisentraut

Specify which versions of the Platform SDK are supported

Anything including Visual Studio 2010 compilers is not yet
supported for building on Windows.

Reduce the initial size of local lock hash to 16 entries.

The hash table is seq scanned at transaction end, to release all locks,
and making the hash table larger than necessary makes that slower. With
very simple queries, that overhead can amount to a few percent of the total
CPU time used.

At the moment, backend startup needs 6 locks, and a simple query with one
table and index needs 3 locks. 16 is enough for even quite complicated
transactions, and it will grow automatically if it fills up.

Rename pg_regress option --multibyte to --encoding

Also refactor things a little bit so that the same methods for setting
test locale and encoding can be used everywhere.

Update release notes for releases 9.0.4, 8.4.8, 8.3.15, and 8.2.21.

Advise Debian/Ubuntu users to use openjade1.3.

The latest openjade packages for Ubuntu 10.10 seg fault when building
our documentation.

Josh Berkus

Remove obsolete comment.

The lock level for adding a parent table is now ShareUpdateExclusiveLock;
see commit fbcf4b92aa64d4577bcf25925b055316b978744a.  This comment didn't
get updated to match, but it doesn't seem important to mention this detail
here, so rather than updating it now, just take it out.

Fix toast table creation.

Instead of using slightly-too-clever heuristics to decide when we must
create a TOAST table, just check whether one is needed every time the
table is altered.  Checking whether a toast table is needed is cheap
enough that we needn't worry about doing it on every ALTER TABLE command,
and the previous coding is apparently prone to accidental breakage:
commit 04e17bae50a73af524731fa11210d5c3f7d8e1f9 broken ALTER TABLE ..
SET STORAGE, which moved some actions from AT_PASS_COL_ATTRS to
AT_PASS_MISC, and commit 6c5723998594dffa5d47c3cf8c96ccf89c033aae broke
ALTER TABLE .. ADD COLUMN by changing the way that adding columns
recurses into child tables.

Noah Misch, with one comment change by me

Ensure mark_dummy_rel doesn't create dangling pointers in RelOptInfos.

When we are doing GEQO join planning, the current memory context is a
short-lived context that will be reset at the end of geqo_eval().  However,
the RelOptInfos for base relations are set up before that and then re-used
across many GEQO cycles.  Hence, any code that modifies a baserel during
join planning has to be careful not to put pointers to the short-lived
context into the baserel struct.  mark_dummy_rel got this wrong, leading to
easy-to-reproduce-once-you-know-how crashes in 8.4, as reported off-list by
Leo Carson of SDSC.  Some improvements made in 9.0 make it difficult to
demonstrate the crash in 9.0 or HEAD; but there's no doubt that there's
still a risk factor here, so patch all branches that have the function.
(Note: 8.3 has a similar function, but it's only applied to joinrels and
thus is not a hazard.)

Update time zone data files to tzdata release 2011f.

DST law changes in Chile, Cuba, Falkland Islands, Morocco, Samoa, Turkey.
Historical corrections for South Australia, Alaska, Hawaii.

Avoid incorrectly granting replication to roles created with NOSUPERUSER.

Andres Freund

On HP/UX, the structs used by ioctl(SIOCGLIFCONF) are named differently
than on other platforms, and only IPv6 addresses are returned. Because of
those two issues, fall back to ioctl(SIOCGIFCONF) on HP/UX, so that it at
least compiles and finds IPv4 addresses. This function is currently only
used for interpreting samehost/samenet in pg_hba.conf, which isn't that
critical.

Revert the patch to check if we've reached end-of-backup also when doing
crash recovery, and throw an error if not. hubert depesz lubaczewski pointed
out that that situation also happens in the crash recovery following a
system crash that happens during an online backup.

We might want to do something smarter in 9.1, like put the check back for
backups taken with pg_basebackup, but that's for another patch.

On IA64 architecture, we check the depth of the register stack in addition
to the regular stack. The code to do that is platform and compiler specific,
add support for the HP-UX native compiler.

Add some useful cross-references to the CREATE EXTENSION reference page.

Per a suggestion from Josh Kupershmidt, though I modified his patch
quite a lot.

Pass collations to functions in FunctionCallInfoData, not FmgrInfo.

Since collation is effectively an argument, not a property of the function,
FmgrInfo is really the wrong place for it; and this becomes critical in
cases where a cached FmgrInfo is used for varying purposes that might need
different collation settings.  Fix by passing it in FunctionCallInfoData
instead.  In particular this allows a clean fix for bug #5970 (record_cmp
not working).  This requires touching a bit more code than the original
method, but nobody ever thought that collations would not be an invasive
patch...

Suppress compiler warnings about "value computed is not used".

The recent patch to remove gcc 4.6 warnings created some new ones, at
least on my rather old gcc version.  Try to make everybody happy by
casting to "void" when we just want to discard the result.

Be more wary of missing statistics in eqjoinsel_semi().

In particular, if we don't have real ndistinct estimates for both sides,
fall back to assuming that half of the left-hand rows have join partners.
This is what was done in 8.2 and 8.3 (cf nulltestsel() in those versions).
It's pretty stupid but it won't lead us to think that an antijoin produces
no rows out, as seen in recent example from Uwe Schroeder.

Fix RI_Initial_Check to use a COLLATE clause when needed in its query.

If the referencing and referenced columns have different collations,
the parser will be unable to resolve which collation to use unless it's
helped out in this way.  The effects are sometimes masked, if we end up
using a non-collation-sensitive plan; but if we do use a mergejoin
we'll see a failure, as recently noted by Robert Haas.

The SQL spec states that the referenced column's collation should be used
to resolve RI checks, so that's what we do.  Note however that we currently
don't append a COLLATE clause when writing a query that examines only the
referencing column.  If we ever support collations that have varying
notions of equality, that will have to be changed.  For the moment, though,
it's preferable to leave it off so that we can use a normal index on the
referencing column.

Clean up most -Wunused-but-set-variable warnings from gcc 4.6

This warning is new in gcc 4.6 and part of -Wall.  This patch cleans
up most of the noise, but there are some still warnings that are
trickier to remove.

Teach pattern_fixed_prefix() about collations.

This is necessary, not optional, now that ILIKE and regexes are collation
aware --- else we might derive a wrong comparison constant for index
optimized pattern matches.

TransferPredicateLocksToNewTarget should initialize a new lock
entry's commitSeqNo to that of the old one being transferred, or take
the minimum commitSeqNo if it is merging two lock entries.

Also, CreatePredicateLock should initialize commitSeqNo for to
InvalidSerCommitSeqNo instead of to 0. (I don't think using 0 would
actually affect anything, but we should be consistent.)

I also added a couple of assertions I used to track this down: a
lock's commitSeqNo should never be zero, and it should be
InvalidSerCommitSeqNo if and only if the lock is not held by
OldCommittedSxact.

Dan Ports, to fix leak of predicate locks reported by YAMAMOTO Takashi.

Fix the size of predicate lock manager's shared memory hash tables at creation.

This way they don't compete with the regular lock manager for the slack shared
memory, making the behavior more predictable.

Add some more mapping macros for Microsoft wide-character API.

Per buildfarm.

Insert dummy "break"s to silence compiler complaints.

Apparently some compilers dislike a case label with nothing after it.
Per buildfarm.

Remove CRLF line endings in new cube results file.

Teach regular expression operators to honor collations.

This involves getting the character classification and case-folding
functions in the regex library to use the collations infrastructure.
Most of this work had been done already in connection with the upper/lower
and LIKE logic, so it was a simple matter of transposition.

While at it, split out these functions into a separate source file
regc_pg_locale.c, so that they can be correctly labeled with the Postgres
project's license rather than the Scriptics license.  These functions are
100% Postgres-written code whereas what remains in regc_locale.c is still
mostly not ours, so lumping them both under the same copyright notice was
getting more and more misleading.

Adjust regression tests on cube and ECPG for MinGW 64 bit compiler.

Backport to 9.0, we're not supporting this compiler on earlier releases.

Don't make "replication" magical as a user name, only as a database name, in pg_hba.conf.

Per gripe from Josh Berkus.

pgindent run before PG 9.1 beta 1.

Clean up overly complex code for issuing some related error messages.

The original version was unreadable, and not mechanically checkable
either.

Add collation support on Windows (MSVC build)

There is not yet support in initdb to populate the pg_collation
catalog, but if that is done manually, the rest should work.

Fix ILIKE to honor collation when working in single-byte encodings.

The original collation patch only fixed the multi-byte code path.
This change also ensures that ILIKE's idea of the case-folding rules
is exactly the same as str_tolower's.

Remove collate.linux.utf8.sql's assumptions about ".utf8" in locale names.

Tweak the test so that it does not depend on the platform using ".utf8" as
the extension signifying that a locale uses UTF8 encoding.  For the most
part this just requires using the abbreviated collation names "en_US" etc,
though I had to work a bit harder on the collation creation tests.

This opens the door to using the test on platforms that spell locales
differently, for example ".utf-8" or ".UTF-8".  Also, the test is now
somewhat useful with server encodings other than UTF8; though depending on
which encoding is selected, different subsets of it will fail for lack of
character set support.

Adjust collation determination rules as per discussion.

Remove crude hack that tried to propagate collation through a
function-returning-record, ie, from the function's arguments to individual
fields selected from its result record.  That is just plain inconsistent,
because the function result is composite and cannot have a collation;
and there's no hope of making this kind of action-at-a-distance work
consistently.  Adjust regression test cases that expected this to happen.

Meanwhile, the behavior of casting to a domain with a declared collation
stays the same as it was, since that seemed to be the consensus.

Don't show unusable collations in psql's \dO command.

"Unusable" collations are those not matching the current database's
encoding.  The former behavior inconsistently showed such collations
some of the time, depending on the details of the pattern argument.

Latest consolidated typedef list from buildfarm.

Clean up minor collation issues in indxpath.c.

Get rid of bogus collation test in match_special_index_operator (even for
ILIKE, the pattern match operator's collation doesn't matter here, and even
if it did the test was testing the wrong thing).
Fix broken looping logic in expand_indexqual_rowcompare.
Add collation check in match_clause_to_ordering_op.
Make naming and argument ordering more consistent; improve comments.

Fix make_greater_string to not have an undocumented collation assumption.

The previous coding worked only if ltproc->fn_collation was always either
DEFAULT_COLLATION_OID or a C-compatible locale.  While that's true at the
moment, it wasn't documented (and in fact wasn't true when this code was
committed...).  But it only takes a couple more lines to make its internal
caching behavior locale-aware, so let's do that.

Truncate the predicate lock SLRU to empty, instead of almost empty.

Otherwise, the SLRU machinery can get confused and think that the SLRU
has wrapped around.  Along the way, regardless of whether we're
truncating all of the SLRU or just some of it, flush pages after
truncating, rather than before.

Kevin Grittner

Tweak collation setup for GIN index comparison functions.

Honor index column's collation spec if there is one, don't go to the
expense of calling get_typcollation when we can reasonably assume that
all GIN storage types will use default collation, and be sure to set
a collation for the comparePartialFn too.