and UPDATE are clearly covered by the term.

rather than being disallowed.

require at least two characters for uniqueness.   This now matches the
behavior of other boolean strings we support, per report from Gurjeet
Singh.

cases.  Operator classes now exist within "operator families".  While most
families are equivalent to a single class, related classes can be grouped
into one family to represent the fact that they are semantically compatible.
Cross-type operators are now naturally adjunct parts of a family, without
having to wedge them into a particular opclass as we had done originally.

This commit restructures the catalogs and cleans up enough of the fallout so
that everything still works at least as well as before, but most of the work
needed to actually improve the planner's behavior will come later.  Also,
there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way
to create a new family right now is to allow CREATE OPERATOR CLASS to make
one by default.  I owe some more documentation work, too.  But that can all
be done in smaller pieces once this infrastructure is in place.

work effectively with open source communities.

added.

< 	o Improve xid wraparound detection by recording per-table rather
< 	  than per-database

Interpret a dbName param to PQsetdbLogin as a conninfo string if it contains an = sign. Tom Lane and Andrew Dunstan.

operator strategy numbers, ie, GiST and GIN.  This is almost cosmetic
enough to not need a catversion bump, but since the opr_sanity regression
test has to change in sync with the catalog entry, I figured I'd better
do one.

<   While PostgreSQL clients runs fine limited-resource environments, the
>   While PostgreSQL clients runs fine in limited-resource environments, the

< * Make CLUSTER preserve recently-dead tuples per MVCC requirements
> 	o Make CLUSTER preserve recently-dead tuples per MVCC requirements

are all in new-in-8.2 logic associated with indexability of ScalarArrayOpExpr
(IN-clauses) or amortization of indexscan costs across repeated indexscans
on the inside of a nestloop.  In particular:

Fix some logic errors in the estimation for multiple scans induced by a
ScalarArrayOpExpr indexqual.

Include a small cost component in bitmap index scans to reflect the costs of
manipulating the bitmap itself; this is mainly to prevent a bitmap scan from
appearing to have the same cost as a plain indexscan for fetching a single
tuple.

Also add a per-index-scan-startup CPU cost component; while prior releases
were clearly too pessimistic about the cost of repeated indexscans, the
original 8.2 coding allowed the cost of an indexscan to effectively go to zero
if repeated often enough, which is overly optimistic.

Pay some attention to index correlation when estimating costs for a nestloop
inner indexscan: this is significant when the plan fetches multiple heap
tuples per iteration, since high correlation means those tuples are probably
on the same or adjacent heap pages.

was removed in an unexplainable moment of brain fade.

properly.

Remove SGML docs about openjade performance patch, and instead add
comment in style sheet where indenting code is commented out.

Backpatch to 8.2.X.

>
> * Embedded server (not wanted)
>
>   While PostgreSQL clients runs fine limited-resource environments, the
>   server requires multiple processes and a stable pool of resources to
>   run reliabily and efficiently.  Stripping down the PostgreSQL server
>   to run in the same process address space as the client application
>   would add too much complexity and failure cases.

< * Consider changing documentation from SGML to XML
> * Consider changing documentation format from SGML to XML
<   http://archives.postgresql.org/pgsql-docs/2006-12/msg00033.php
>   http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php

>
> * Consider changing documentation from SGML to XML
>
>   http://archives.postgresql.org/pgsql-docs/2006-12/msg00033.php
>

time.

correct, add comments about other multiple runs in the Makefile.

Backpatch to 8.2.X.

necessary.

< * Have EXPLAIN ANALYZE highlight poor optimizer estimates
> * Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and
>   actual row counts differ by a specified percentage

joinclause doesn't use any outer-side vars) requires a "bushy" plan to be
created.  The normal heuristic to avoid joins with no joinclause has to be
overridden in that case.  Problem is new in 8.2; before that we forced the
outer join order anyway.  Per example from Teodor.

< * Allow REINDEX CONCURRENTLY

> * Allow REINDEX CONCURRENTLY

works, but some platform templates overwrote it without asking.

NULLs.