Update config.guess and config.sub

Fix dependency tracking for src/port/%_srv.o files

Because they use their own compilation rule, they don't use the
dependency tracking logic from Makefile.global.  To make sure that
dependency tracking works anyway for the *_srv.o files, depend on
their *.o siblings as well, which do have proper dependencies.  It's a
hack that might fail someday if there is a *_srv.o without a
corresponding *.o, but it works for now (and those would probably go
into src/backend/port/ anyway).

Fix misleading comments

Josh Kupershmidt

Remove strdup, strtol, strtoul from libpgport

These should not be needed anymore, at least after the recent port
removals.  So let's see whether we can do without them.

Fix pg_config.h make rule

According to the Autoconf documentation, there should be a make rule

pg_config.h: stamp-h

so that with the right setup around this, a change in pg_config.h.in
will trigger a rebuild of everything that depends on pg_config.h.  But
this doesn't always work, sometimes you need to run make twice to get
everything up to date after a change of pg_config.h.in.

The fix is to write the rule as

pg_config.h: stamp-h ;

instead (with an empty command instead of no command).  This is what
Automake-generated makefiles effectively do, so it seems safe to be on
this side.

It's not actually clear why this is (apparently) more correct.  It's
been posted to
<http://lists.gnu.org/archive/html/help-make/2012-04/msg00058.html>
without response so far.

Make "unexpected EOF" messages DEBUG1 unless in an open transaction

"Unexpected EOF on client connection" without an open transaction
is mostly noise, so turn it into DEBUG1. With an open transaction it's
still indicating a problem, so keep those as ERROR, and change the message
to indicate that it happened in a transaction.

Document that it is the pgsql version we are matching for psqlrc
version-specific files, not the server version.

Revert typo fix 768c3affd44d1dcb4e43e2e006c642524714c2a4;  I was wrong.

Fix psql doc typo.

Overdue code review for transaction-level advisory locks patch.

Commit 62c7bd31c8878dd45c9b9b2429ab7a12103f3590 had assorted problems, most
visibly that it broke PREPARE TRANSACTION in the presence of session-level
advisory locks (which should be ignored by PREPARE), as per a recent
complaint from Stephen Rees.  More abstractly, the patch made the
LockMethodData.transactional flag not merely useless but outright
dangerous, because in point of fact that flag no longer tells you anything
at all about whether a lock is held transactionally.  This fix therefore
removes that flag altogether.  We now rely entirely on the convention
already in use in lock.c that transactional lock holds must be owned by
some ResourceOwner, while session holds are never so owned.  Setting the
locallock struct's owner link to NULL thus denotes a session hold, and
there is no redundant marker for that.

PREPARE TRANSACTION now works again when there are session-level advisory
locks, and it is also able to transfer transactional advisory locks to the
prepared transaction, but for implementation reasons it throws an error if
we hold both types of lock on a single lockable object.  Perhaps it will be
worth improving that someday.

Assorted other minor cleanup and documentation editing, as well.

Back-patch to 9.1, except that in the 9.1 branch I did not remove the
LockMethodData.transactional flag for fear of causing an ABI break for
any external code that might be examining those structs.

doc: Fix for too many brackets in command synopses on man pages

The default for the choice attribute of the <arg> element is "opt",
which would normally put the argument inside brackets.  But the DSSSL
stylesheets contain a hack that treats <arg> directly inside <group>
specially, so that <group><arg>-x</arg><arg>-y</arg></group> comes out
as [ -x | -y ] rather than [ [-x] | [-y] ], which it would technically
be.  But when building man pages, this doesn't work, and so the
command synopses on the man pages contain lots of extra brackets.

By putting choice="opt" or choice="plain" explicitly on every <arg>
and <group> element, we avoid any toolchain dependencies like that,
and it also makes it clearer in the source code what is meant.

In passing, make some small corrections in the documentation about
which arguments are really optional or not.

Remove BSD/OS (BSDi) port.  There are no known users upgrading to
Postgres 9.2, and perhaps no existing users either.

Mark git_changelog examples with the proper executable names.

Add missing parenthesis in comment.

PL/Python: Improve test coverage

Add test cases for inline handler of plython2u (when using that
language name), and for result object element assignment.  There is
now at least one test case for every top-level functionality, except
plpy.Fatal (annoying to use in regression tests) and result object
slice retrieval and slice assignment (which are somewhat broken).

PL/Python: Fix crash in functions returning SETOF and using SPI

Allocate PLyResultObject.tupdesc in TopMemoryContext, because its
lifetime is the lifetime of the Python object and it shouldn't be
freed by some other memory context, such as one controlled by SPI.  We
trust that the Python object will clean up its own memory.

Before, this would crash the included regression test case by trying
to use memory that was already freed.

reported by Asif Naeem, analysis by Tom Lane

Even more duplicate word removal, in the spirit of the season

Avoid repeated CLOG access from heap_hot_search_buffer.

At the time we check whether the tuple is dead to all running
transactions, we've already verified that it isn't visible to our
scan, setting hint bits if appropriate.  So there's no need to
recheck CLOG for the all-dead test we do just a moment later.
So, add HeapTupleIsSurelyDead() to test the appropriate condition
under the assumption that all relevant hit bits are already set.

Review by Tom Lane.

Further corrections from the department of redundancy department.

Thom Brown

More duplicate word removal.

Remove duplicate words in comments.

Found these with grep -r "for for ".

Kill some remaining references to SVR4 and univel.

Both terms still appear in a few places, but I thought it best to leave
those alone in context.

Tweak psql to print row counts when \x auto chooses non-expanded output.

Noah Misch

Remove dead ports

Remove the following ports:

- dgux
- nextstep
- sunos4
- svr4
- ultrix4
- univel

These are obsolete and not worth rescuing.  In most cases, there is
circumstantial evidence that they wouldn't work anymore anyway.

Improve markup of cmdsynopsis elements

Add more markup in particular so that the command options appear
consistently in monospace in the HTML output.

On the vacuumdb reference page, remove listing all the possible
options in the synopsis.  They have become too many now; we have the
detailed options list for that.

Fix display of <command> elements on man pages

We had changed this from the default bold to monospace for all output
formats, but for man pages, this creates visual inconsistencies, so
revert to the default for man pages.

Converge all SQL-level statistics timing values to float8 milliseconds.

This patch adjusts the core statistics views to match the decision already
taken for pg_stat_statements, that values representing elapsed time should
be represented as float8 and measured in milliseconds.  By using float8,
we are no longer tied to a specific maximum precision of timing data.
(Internally, it's still microseconds, but we could now change that without
needing changes at the SQL level.)

The columns affected are
pg_stat_bgwriter.checkpoint_write_time
pg_stat_bgwriter.checkpoint_sync_time
pg_stat_database.blk_read_time
pg_stat_database.blk_write_time
pg_stat_user_functions.total_time
pg_stat_user_functions.self_time
pg_stat_xact_user_functions.total_time
pg_stat_xact_user_functions.self_time

The first four of these are new in 9.2, so there is no compatibility issue
from changing them.  The others require a release note comment that they
are now double precision (and can show a fractional part) rather than
bigint as before; also their underlying statistics functions now match
the column definitions, instead of returning bigint microseconds.

Mark ReThrowError() with attribute noreturn

All related functions were already so marked.

Remove duplicate word in comment.

Noted by Peter Geoghegan.

Add comments suggesting usage of git_changelog to generate release notes.

Rename I/O timing statistics columns to blk_read_time and blk_write_time.

This seems more consistent with the pre-existing choices for names of
other statistics columns.  Rename assorted internal identifiers to match.

Rename track_iotiming GUC to track_io_timing.

This spelling seems significantly more readable to me.

Further editorialization on the new documentation for statistics views.

Get rid of the per-column documentation of underlying functions, which did
far more to clutter the view descriptions than it did to be helpful, and
was rather incomplete and typo-ridden anyway.  Instead suggest that people
consult the definitions of the standard views to see the underlying
functions.

The older functions for obtaining individual facts about backends are now
somewhat obsoleted by pg_stat_get_activity, which means that they are not
documented by any standard view.  So I put that information into a separate
table.  (Maybe we should just deprecate them instead?)

In passing, fix a couple more documentation errors.

Change return type of ExceptionalCondition to void and mark it noreturn

In ancient times, it was thought that this wouldn't work because of
TrapMacro/AssertMacro, but changing those to use a comma operator
appears to work without compiler warnings.

Simplify makefile rule

Instead of writing out the .c -> .o rule, use the default one, so that
dependency tracking can be used.

Make a copy-editing pass over the new documentation for statistics views.

Fix a bunch of typos, improve markup, make wording more uniform, rearrange
some material.  No substantive changes.

Adjust timing units in pg_stat_statements.

Display total time and I/O timings in milliseconds, for consistency with
the units used for timings in the core statistics views.  The columns
remain of float8 type, so that sub-msec precision is available.  (At some
point we will probably want to convert the core views to use float8 type
for the same reason, but this patch does not touch that issue.)

This is a release-note-requiring change in the meaning of the total_time
column.  The I/O timing columns are new as of 9.2, so there is no
compatibility impact from redefining them.

Do some minor copy-editing in the documentation, too.

Clear I/O timing counters after sending them to the stats collector.

This oversight caused the reported times to accumulate in an O(N^2)
fashion the longer a backend runs.

PL/Python: Update list of supported environment variables

Fix printing of whole-row Vars at top level of a SELECT targetlist.

Normally whole-row Vars are printed as "tabname.*".  However, that does not
work at top level of a targetlist, because per SQL standard the parser will
think that the "*" should result in column-by-column expansion; which is
not at all what a whole-row Var implies.  We used to just print the table
name in such cases, which works most of the time; but it fails if the table
name matches a column name available anywhere in the FROM clause.  This
could lead for instance to a view being interpreted differently after dump
and reload.  Adding parentheses doesn't fix it, but there is a reasonably
simple kluge we can use instead: attach a no-op cast, so that the "*" isn't
syntactically at top level anymore.  This makes the printing of such
whole-row Vars a lot more consistent with other Vars, and may indeed fix
more cases than just the reported one; I'm suspicious that cases involving
schema qualification probably didn't work properly before, either.

Per bug report and fix proposal from Abbas Butt, though this patch is quite
different in detail from his.

Back-patch to all supported versions.

Add options to git_changelog for use in major release note creation:

--details-after
--master-only
--oldest-first

Fix syslogger's rotation disable/re-enable logic.

If it fails to open a new log file, the syslogger assumes there's something
wrong with its parameters (such as log_directory), and stops attempting
automatic time-based or size-based log file rotations.  Sending it SIGHUP
is supposed to start that up again.  However, the original coding for that
was really bogus, involving clobbering a couple of GUC variables and hoping
that SIGHUP processing would restore them.  Get rid of that technique in
favor of maintaining a separate flag showing we've turned rotation off.
Per report from Mark Kirkwood.

Also, the syslogger will automatically attempt to create the log_directory
directory if it doesn't exist, but that was only happening at startup.
For consistency and ease of use, it should do the same whenever the value
of log_directory is changed by SIGHUP.

Back-patch to all supported branches.

Prevent index-only scans from returning wrong answers under Hot Standby.

The alternative of disallowing index-only scans in HS operation was
discussed, but the consensus was that it was better to treat marking
a page all-visible as a recovery conflict for snapshots that could still
fail to see XIDs on that page.  We may in the future try to soften this,
so that we simply force index scans to do heap fetches in cases where
this may be an issue, rather than throwing a hard conflict.

Improve documentation around historical calendar rules.

Get rid of section 8.5.6 (Date/Time Internals), which appears to confuse
people more than it helps, and anyway discussion of Postgres' internal
datetime calculation methods seems pretty out of place here.  Instead,
make datatype.sgml just say that we follow the Gregorian calendar (a bit
of specification not previously present anywhere in that chapter :-()
and link to the History of Units appendix for more info.  Do some mild
editorialization on that appendix, too, to make it clearer that we are
following proleptic Gregorian calendar rules rather than anything more
historically accurate.

Per a question from Florence Cousin and subsequent discussion in
pgsql-docs.

Fix oversight in recent parameterized-path patch.

bitmap_scan_cost_est() has to be able to cope with a BitmapOrPath, but
I'd taken a shortcut that didn't work for that case.  Noted by Heikki.
Add some regression tests since this area is evidently under-covered.

PL/Python: Accept strings in functions returning composite types

Before 9.1, PL/Python functions returning composite types could return
a string and it would be parsed using record_in.  The 9.1 changes made
PL/Python only expect dictionaries, tuples, or objects supporting
getattr as output of composite functions, resulting in a regression
and a confusing error message, as the strings were interpreted as
sequences and the code for transforming lists to database tuples was
used.  Fix this by treating strings separately as before, before
checking for the other types.

The reason why it's important to support string to database tuple
conversion is that trigger functions on tables with composite columns
get the composite row passed in as a string (from record_out).
Without supporting converting this back using record_in, this makes it
impossible to implement pass-through behavior for these columns, as
PL/Python no longer accepts strings for composite values.

A better solution would be to fix the code that transforms composite
inputs into Python objects to produce dictionaries that would then be
correctly interpreted by the Python->PostgreSQL counterpart code.  But
that would be too invasive to backpatch to 9.1, and it is too late in
the 9.2 cycle to attempt it.  It should be revisited in the future,
though.

Reported as bug #6559 by Kirill Simonov.

Jan Urbański

psql: Tab completion updates

Add/complete support for:

- ALTER DOMAIN / VALIDATE CONSTRAINT
- ALTER DOMAIN / RENAME
- ALTER DOMAIN / RENAME CONSTRAINT
- ALTER TABLE / RENAME CONSTRAINT

Modify create_index regression test to avoid intermittent failures.

We have been seeing intermittent buildfarm failures due to a query
sometimes not using an index-only scan plan, because a background
auto-ANALYZE prevented the table's all-visible bits from being set
immediately, thereby causing the estimated cost of an index-only scan
to go up considerably.  Adjust the test case so that a bitmap index scan is
preferred instead, which serves equally well for the purpose the test case
is actually meant for.  (Of course, it would be better to eliminate the
interference from auto-ANALYZE, but I see no low-risk way to do that,
so any such fix will have to be left for 9.3 or later.)

Fix planner's handling of RETURNING lists in writable CTEs.

setrefs.c failed to do "rtoffset" adjustment of Vars in RETURNING lists,
which meant they were left with the wrong varnos when the RETURNING list
was in a subquery.  That was never possible before writable CTEs, of
course, but now it's broken.  The executor fails to notice any problem
because ExecEvalVar just references the ecxt_scantuple for any normal
varno; but EXPLAIN breaks when the varno is wrong, as illustrated in a
recent complaint from Bartosz Dmytrak.

Since the eventual rtoffset of the subquery is not known at the time
we are preparing its plan node, the previous scheme of executing
set_returning_clause_references() at that time cannot handle this
adjustment.  Fortunately, it turns out that we don't really need to do it
that way, because all the needed information is available during normal
setrefs.c execution; we just have to dig it out of the ModifyTable node.
So, do that, and get rid of the kluge of early setrefs processing of
RETURNING lists.  (This is a little bit of a cheat in the case of inherited
UPDATE/DELETE, because we are not passing a "root" struct that corresponds
exactly to what the subplan was built with.  But that doesn't matter, and
anyway this is less ugly than early setrefs processing was.)

Back-patch to 9.1, where the problem became possible to hit.

Fix edge-case behavior of pg_next_dst_boundary().

Due to rather sloppy thinking (on my part, I'm afraid) about the
appropriate behavior for boundary conditions, pg_next_dst_boundary() gave
undefined, platform-dependent results when the input time is exactly the
last recorded DST transition time for the specified time zone, as a result
of fetching values one past the end of its data arrays.

Change its specification to be that it always finds the next DST boundary
*after* the input time, and adjust code to match that.  The sole existing
caller, DetermineTimeZoneOffset, doesn't actually care about this
distinction, since it always uses a probe time earlier than the instant
that it does care about.  So it seemed best to me to change the API to make
the result=1 and result=0 cases more consistent, specifically to ensure
that the "before" outputs always describe the state at the given time,
rather than hacking the code to obey the previous API comment exactly.

Per bug #6605 from Sergey Burladyan.  Back-patch to all supported versions.

Remove prototype for nonexistent function.

Another trivial comment-typo fix.

PL/Python: Improve error messages

Standardize indentation of XSL files

Predominant standard is two spaces, so adjust outliers to that.

entab: Improve makefile

A few simplifications and stylistic improvements, found while grepping
around for makefile problems elsewhere.

Fix minor stylistic issue

Casts to or from a domain type are ignored; warn and document.

Prohibiting this outright would break dumps taken from older versions
that contain such casts, which would create far more pain than is
justified here.

Per report by Jaime Casanova and subsequent discussion.

Another typographical correction.

Noted by Guillaume Smet.

Lots of doc corrections.

Josh Kupershmidt

Rearrange lazy_scan_heap to avoid visibility map race conditions.

We must set the visibility map bit before releasing our exclusive lock
on the heap page; otherwise, someone might clear the heap page bit
before we set the visibility map bit, leading to a situation where the
visibility map thinks the page is all-visible but it's really not.

This problem has existed since 8.4, but it wasn't critical before we
had index-only scans, since the worst case scenario was that the page
wouldn't get vacuumed until the next scan_all vacuum.

Along the way, a couple of minor, related improvements: (1) if we
pause the heap scan to do an index vac cycle, release any visibility
map page we're holding, since really long-running pins are not good
for a variety of reasons; and (2) warn if we see a page that's marked
all-visible in the visibility map but not on the page level, since
that should never happen any more (it was allowed in previous
releases, but not in 9.2).

Reduce hash size for compute_array_stats, compute_tsvector_stats.

The size is only a hint, but a big hint chews up a lot of memory without
apparently improving performance much.

Analysis and patch by Noah Misch.

Minor improvements for CHECK NO INHERIT documentation.

Fix typo spotted by Thom Brown, and improve wording in another area
where Thom spotted a typo.

Fix some typos

Josh Kupershmidt

Use fuzzy not exact cost comparison for the final tie-breaker in add_path.

Instead of an exact cost comparison, use a fuzzy comparison with 1e-10
delta after all other path metrics have proved equal.  This is to avoid
having platform-specific roundoff behaviors determine the choice when
two paths are really the same to our cost estimators.  Adjust the
recently-added test case that made it obvious we had a problem here.

Recast "ONLY" column CHECK constraints as NO INHERIT

The original syntax wasn't universally loved, and it didn't allow its
usage in CREATE TABLE, only ALTER TABLE.  It now works everywhere, and
it also allows using ALTER TABLE ONLY to add an uninherited CHECK
constraint, per discussion.

The pg_constraint column has accordingly been renamed connoinherit.

This commit partly reverts some of the changes in
61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and
psql bits, because now pg_get_constraintdef includes the necessary NO
INHERIT within the constraint definition.

Author: Nikhil Sontakke
Some tweaks by me

Adjust join_search_one_level's handling of clauseless joins.

For an initial relation that lacks any join clauses (that is, it has to be
cartesian-product-joined to the rest of the query), we considered only
cartesian joins with initial rels appearing later in the initial-relations
list.  This creates an undesirable dependency on FROM-list order.  We would
never fail to find a plan, but perhaps we might not find the best available
plan.  Noted while discussing the logic with Amit Kapila.

Improve the comments a bit in this area, too.

Arguably this is a bug fix, but given the lack of complaints from the
field I'll refrain from back-patching.

Revise parameterized-path mechanism to fix assorted issues.

This patch adjusts the treatment of parameterized paths so that all paths
with the same parameterization (same set of required outer rels) for the
same relation will have the same rowcount estimate.  We cache the rowcount
estimates to ensure that property, and hopefully save a few cycles too.
Doing this makes it practical for add_path_precheck to operate without
a rowcount estimate: it need only assume that paths with different
parameterizations never dominate each other, which is close enough to
true anyway for coarse filtering, because normally a more-parameterized
path should yield fewer rows thanks to having more join clauses to apply.

In add_path, we do the full nine yards of comparing rowcount estimates
along with everything else, so that we can discard parameterized paths that
don't actually have an advantage.  This fixes some issues I'd found with
add_path rejecting parameterized paths on the grounds that they were more
expensive than not-parameterized ones, even though they yielded many fewer
rows and hence would be cheaper once subsequent joining was considered.

To make the same-rowcounts assumption valid, we have to require that any
parameterized path enforce *all* join clauses that could be obtained from
the particular set of outer rels, even if not all of them are useful for
indexing.  This is required at both base scans and joins.  It's a good
thing anyway since the net impact is that join quals are checked at the
lowest practical level in the join tree.  Hence, discard the original
rather ad-hoc mechanism for choosing parameterization joinquals, and build
a better one that has a more principled rule for when clauses can be moved.
The original rule was actually buggy anyway for lack of knowledge about
which relations are part of an outer join's outer side; getting this right
requires adding an outer_relids field to RestrictInfo.

Untabify DSSSL and XSL files and add to check-tabs target

Like with SGML files, using tabs in these files is confusing and
unnecessary.

Remove bogus comment from HeapTupleSatisfiesNow.

This has been wrong for a really long time.  We don't use two-phase
locking to protect against serialization anomalies.

Per discussion on pgsql-hackers about 2011-03-07; original report
by Dan Ports.

Finish rename of FastPathStrongLocks to FastPathStrongRelationLocks.

Commit 8e5ac74c1249820ca55481223a95b9124b4a4f95 tried to do this renaming,
but I relied on gcc to tell me where I needed to make changes, instead of
grep.

Noted by Jeff Davis.

Tighten up error recovery for fast-path locking.

The previous code could cause a backend crash after BEGIN; SAVEPOINT a;
LOCK TABLE foo (interrupted by ^C or statement timeout); ROLLBACK TO
SAVEPOINT a; LOCK TABLE foo, and might have leaked strong-lock counts
in other situations.

Report by Zoltán Böszörményi; patch review by Jeff Davis.

Fix incorrect comment in SetBufferCommitInfoNeedsSave().

Noah Misch spotted the fact that the old comment is in fact incorrect, due
to memory ordering hazards.

After PageSetAllVisible, use MarkBufferDirty.

Previously, we used SetBufferCommitInfoNeedsSave, but that's really
intended for dirty-marks we can theoretically afford to lose, such as
hint bits.  As for 9.2, the PD_ALL_VISIBLE mustn't be lost in this
way, since we could then end up with a heap page that isn't
all-visible and a visibility map page that is all visible, causing
index-only scans to return wrong answers.

Fix copyfuncs/equalfuncs support for ReassignOwnedStmt.

Noah Misch

Fix various infelicities in node functions.

Mostly, this consists of adding support for fields which exist in the
structure but aren't handled by copy/equal/outfuncs; but the create
foreign table case can actually produce garbage output.

Noah Misch

Doc clarification for synchronous_commit.

Fujii Masao

psql: Add tab completion for CREATE/ALTER ROLE name WITH

Previously, the use of the optional key word WITH was not supported.

Josh Kupershmidt

Don't override arguments set via options with positional arguments.

A number of utility programs were rather careless about paremeters
that can be set via both an option argument and a positional
argument. This leads to results which can violate the Principal
Of Least Astonishment. These changes refuse to use positional
arguments to override settings that have been made via positional
arguments. The changes are backpatched to all live branches.

Don't wait for the commit record to be replicated if we wrote no WAL.

When using synchronous replication, we waited for the commit record to be
replicated, but if we our transaction didn't write any other WAL records,
that's not required because we don't even flush the WAL locally to disk in
that case. This lead to long waits when committing a transaction that only
modified a temporary table. Bug spotted by Thom Brown.

Add compatibility information for prepared transaction commands

Fix typo

Kyotaro HORIGUCHI

Install plpgsql.h to to include/server at "make install".

The header file is needed by any module that wants to use the PL/pgSQL
instrumentation plugin interface. Most notably, the pldebugger plugin needs
this. With this patch, it can be built using pgxs, without having the full
server source tree available.

PL/Python: Improve documentation of nrows() method

Clarify that nrows() is the number of rows processed, versus the
number of rows returned, which can be obtained using len.  Also add
tests about that.

PL/Python: Fix crash when colnames() etc. called without result set

The result object methods colnames() etc. would crash when called
after a command that did not produce a result set.  Now they throw an
exception.

discovery and initial patch by Jean-Baptiste Quenot

Add missing descriptions about '--timeout' and '--mode' to help
message. They are already implemented in the source code.
Suggestions about the message formatting from Tom Lane.

Rename synchronous_commit='write' to 'remote_write'.

Fujii Masao, per discussion on pgsql-hackers

pg_size_pretty(numeric)

The output of the new pg_xlog_location_diff function is of type numeric,
since it could theoretically overflow an int8 due to signedness; this
provides a convenient way to format such values.

Fujii Masao, with some beautification by me.

Add description of long options for '-c', '-D', '-l' and '-s'.  Per
discussion of hackers list on 2012/3/10 "missing description initdb
manual".

Update contrib/README

Remove lots of outdated information that is duplicated by the
better-maintained SGML documentation.  In particular, remove the
outdated listing of contrib modules.  Update the installation
instructions to mention CREATE EXTENSION, but don't go into too much
detail.

Document that VALUES can be used in WITH

Fix typo

Etsuro Fujita

Add Peter Geoghegan as additional author of pg_stat_statements.

Remove the "last ditch" code path in join_search_one_level().

So far as I can tell, it is no longer possible for this heuristic to do
anything useful, because the new weaker definition of
have_relevant_joinclause means that any relation with a joinclause must be
considered joinable to at least one other relation.  It would still be
possible for the code block to be entered, for example if there are join
order restrictions that prevent any join of the current level from being
formed; but in that case it's just a waste of cycles to attempt to form
cartesian joins, since the restrictions will still apply.

Furthermore, IMO the existence of this code path can mask bugs elsewhere;
we would have noticed the problem with cartesian joins a lot sooner if
this code hadn't compensated for it in the simplest case.

Accordingly, let's remove it and see what happens.  I'm committing this
separately from the prerequisite changes in have_relevant_joinclause,
just to make the question easier to revisit if there is some fault in
my logic.

Weaken the planner's tests for relevant joinclauses.

We should be willing to cross-join two small relations if that allows us
to use an inner indexscan on a large relation (that is, the potential
indexqual for the large table requires both smaller relations).  This
worked in simple cases but fell apart as soon as there was a join clause
to a fourth relation, because the existence of any two-relation join clause
caused the planner to not consider clauseless joins between other base
relations.  The added regression test shows an example case adapted from
a recent complaint from Benoit Delbosc.

Adjust have_relevant_joinclause, have_relevant_eclass_joinclause, and
has_relevant_eclass_joinclause to consider that a join clause mentioning
three or more relations is sufficient grounds for joining any subset of
those relations, even if we have to do so via a cartesian join.  Since such
clauses are relatively uncommon, this shouldn't affect planning speed on
typical queries; in fact it should help a bit, because the latter two
functions in particular get significantly simpler.

Although this is arguably a bug fix, I'm not going to risk back-patching
it, since it might have currently-unforeseen consequences.

Rename bytea_agg to string_agg and add delimiter argument

Per mailing list discussion, we would like to keep the bytea functions
parallel to the text functions, so rename bytea_agg to string_agg,
which already exists for text.

Also, to satisfy the rule that we don't want aggregate functions of
the same name with a different number of arguments, add a delimiter
argument, just like string_agg for text already has.

Consistently quote encoding and locale names in messages

Grammar corrections.

Christoph Berg

Fix typo in comment.

Update lazy_scan_heap header comment.

The previous comment described how things worked in PostgreSQL 8.2
and prior.

Assorted spelling corrections.

Thom Brown