etc are no longer guaranteed to produce sorted output; per gripe from Ian
Barwick.  Also improve the release note entries about to_timestamp(), per
Brendan Jurd.

      Support the <acronym>IS0 8601</> <type>interval</> syntax

based on private email from Ron.

constants through full joins, as in

	select * from tenk1 a full join tenk1 b using (unique1)
	where unique1 = 42;

which should generate a fairly cheap plan where we apply the constraint
unique1 = 42 in each relation scan.  This had been broken by my patch of
2008-06-27, which is now reverted in favor of a more invasive but hopefully
less incorrect approach.  That patch was meant to prevent incorrect extraction
of OR'd indexclauses from OR conditions above an outer join.  To do that
correctly we need more information than the outerjoin_delay flag can provide,
so add a nullable_relids field to RestrictInfo that records exactly which
relations are nulled by outer joins that are underneath a particular qual
clause.  A side benefit is that we can make the test in create_or_index_quals
more specific: it is now smart enough to extract an OR'd indexclause into the
outer side of an outer join, even though it must not do so in the inner side.
The old coding couldn't distinguish these cases so it could not do either.

Per note from Andrew Dunstan.

mentions in main documentation.

%s that they expand to, per comment from Tom.

approval from Poul-Henning Kamp.

This makes the file the same standard 2-clause BSD as the
rest of PostgreSQL.

	select u&42 from table-with-a-u-column;
Also fix missing SET_YYLLOC() in the {dolqfailed} production that I suppose
this was based on.  The latter is a pre-existing bug, but the only effect
is to misplace the error cursor by one token, so probably not worth
backpatching.

previous patch.

Per note from Tom.

If a currently running item needs an exclusive lock on any item that the candidate items needs
any sort of lock on, or vice versa, then the candidate item is not allowed to run now, and
must wait till later.

tablespaces in an order that has some chance of working.
Per a complaint from Kevin Bailey.

This is a pre-existing bug, but given the lack of prior complaints I'm
not sure it's worth back-patching.  In most cases failure of the DROP
commands wouldn't be that important anyway.

In passing, fix syntax errors in dumpCreateDB()'s queries for old servers;
these were apparently introduced in recent binary_upgrade patch.

(I guess this was a cruise replace mistake.)

the plpgsql documentation about cursors.  Per a suggestion from
Matthew Wakeling.

commit and tag beta1

pg_stat_get_blocks_hit, per suggestion from Robert Haas.

Argentina/San_Luis, Cuba, Jordan (historical correction only), Morocco,
Palestine, Syria, Tunisia.

how this ought to behave for multi-dimensional arrays.  Per discussion,
not having it at all seems better than having it with what might prove
to be the wrong behavior.  We can always add it later when we have consensus
on the correct behavior.