data structures and backend internal APIs.  This solves problems we've seen
recently with inconsistent layout of pg_control between machines that have
32-bit time_t and those that have already migrated to 64-bit time_t.  Also,
we can get out from under the problem that Windows' Unix-API emulation is not
consistent about the width of time_t.

There are a few remaining places where local time_t variables are used to hold
the current or recent result of time(NULL).  I didn't bother changing these
since they do not affect any cross-module APIs and surely all platforms will
have 64-bit time_t before overflow becomes an actual risk.  time_t should
be avoided for anything visible to extension modules, however.

the PATH responsive to the installation prefix, which was the apparent
intent of the previous edit, but not well executed.

higher than zero.  Same problem as just detected in CREATE INDEX
CONCURRENTLY.

Noted while looking for heapscans that might need to start from block
zero.

failed to cover all the ways in which a connection can be initiated in dblink.
Plug the remaining holes.  Also, disallow transient connections in functions
for which that feature makes no sense (because they are only sensible as
part of a sequence of operations on the same connection).  Joe Conway

Security: CVE-2007-6601

hazards.  Instead teach these programs to prompt for a password when
necessary, just like all our other programs.
I did not bother to invent -W switches for them, since the return on
investment seems so low.

switch optional, as is the case for every other one of our programs.
I had already documented its -W as being optional, so this is bringing
the code into line with the docs ...

The original coding leaked memory (at least 8K per crosstab_hash call)
because it allowed the hash table to be allocated as a child of
TopMemoryContext and then never freed it.  Fix that by putting the
hash table under per_query_ctx, instead.  Also get rid of use
of a static variable to point to the hash table.  Aside from being
ugly, that would actively do the wrong thing in the case of re-entrant
calls to crosstab_hash, which are at least theoretically possible
since it was expecting the static variable to stay valid across
a SPI_execute call.

old README file, Bruno Wolff did the bulk of the work, but for some
reason only Hal Snyder was credited here.

since we supported standard FOREIGN KEY constraint syntax.  It was
harmless enough just sitting there, but the prospect of having to
document it is surely more work than it's worth.

but no database changes have been made since the last CommandCounterIncrement.
This should result in a significant improvement in the number of "commands"
that can typically be performed within a transaction before hitting the 2^32
CommandId size limit.  In particular this buys back (and more) the possible
adverse consequences of my previous patch to fix plan caching behavior.

The implementation requires tracking whether the current CommandCounter
value has been "used" to mark any tuples.  CommandCounter values stored into
snapshots are presumed not to be used for this purpose.  This requires some
small executor changes, since the executor used to conflate the curcid of
the snapshot it was using with the command ID to mark output tuples with.
Separating these concepts allows some small simplifications in executor APIs.

Something for the TODO list: look into having CommandCounterIncrement not do
AcceptInvalidationMessages.  It seems fairly bogus to be doing it there,
but exactly where to do it instead isn't clear, and I'm disinclined to mess
with asynchronous behavior during late beta.

inappropriately generic-sounding names.  This is more or less free since
we already forced initdb for the next beta, and it may prevent confusion or
name conflicts (particularly at the C-global-symbol level) down the road.
Per my proposal yesterday.

Adjust contrib/tsearch2 regression results to use XML tag and XML entity descriptions, as now used by core text search default parser.

compatibility module.  Needed to support loading of 8.1-era tsearch2
configuration data.

for() body passed as a parameter, make the macros act as simple headers
to code blocks.

This allows pgindent to be run on these files.

avoid this problem in the future.)

and put it into contrib/tsearch2 compatibility module.

compatibility package.  This supports importing dumps from past versions
using tsearch2, and provides the old names and API for most functions
that were changed.  (rewrite(ARRAY[...]) is a glaring omission, though.)

Pavel Stehule and Tom Lane

about best practice for including the module creation scripts: to wit
that you should suppress NOTICE messages.  This avoids creating
regression failures by adding or removing comment lines in the module
scripts.

Remove setting of search_path in install/uninstall scripts, since unlike
other contrib modules this one does not want to let you change the
installation schema.

itself as libuuid, not libossp-uuid which was the only case expected by
our build support.  Install a configure test to determine which name
to use (and to check that the library is present at all).