line 1324:
"left-hand" should be "right-hand"

BTW: new document looks very good!
And the new configure/build process seems much better then before!

Thanks!

Laser

is the only diff not accounted for by fmgr rewrite...

Thanks Chih-Chang Hsieh <cch@cc.kmu.edu.tw> for finding the bug.

varlena type.  (I did not force initdb, but you won't see the fix
unless you do one.)  Also, make sure all index support operators and
functions are careful not to leak memory for toasted inputs; I had
missed some hash and rtree support ops on this point before.

mostly just on the WAL logfile nowadays.  But if people want to disable
fsync for performance, why should we say no?

value greater than one.  The behavior this sought to disallow doesn't
seem any less confusing than the other behaviors of cached sequences.
Improve wording of some error messages, too.
Update documentation accordingly.  Also add an explanation that
aborted transactions do not roll back their nextval() calls; this
seems to be a FAQ, so it ought to be mentioned here...

or return type.

or return type.

or return type.

length is less than original string length.

As I read it, the spec requires a non-null result in some cases where
one of the inputs is NULL: specifically, if the other endpoint of that
interval is between the endpoints of the other interval, then the result
is known TRUE despite the missing endpoint.  The spec could've been a
lot simpler if they did not intend this behavior.
I did not force an initdb for this change, but if you don't do one you'll
still see the old strict-function behavior.

if the transaction has already been committed ?

transformForUpdate does: it should recurse into subqueries.

It could be recursing into a sub-query where there was already a FOR
UPDATE clause.

work where we can (given that the executor only handles it at top level)
and generate an error where we can't.  Note that while the parser has
been allowing views to say SELECT FOR UPDATE for a few weeks now, that
hasn't actually worked until just now.

update VERSION to 7.1beta1..

through to here yet.

the installed header file set.

an error at end of transaction ... and I did *not* like it.  Reduce ERROR
to NOTICE so that this situation doesn't cause an infinite loop.

an error as we used to.  In an OUTER JOIN scenario, retrieving a null
CTID from one of the input relations is entirely expected.  We still
want to lock the input rows from the other relations, so just ignore
the null and keep going.

I believe this should fix the issue that Philip Warner
noticed about the check for unique constraints meeting the
referenced keys of a foreign key constraint allowing the
specification of a subset of a foreign key instead of
rejecting it.  I also added tests for a base case of
this to the foreign key and alter table tests and patches
for expected output.