have WAL, outer joins, and TOAST.

known unique (eg, it is a SELECT DISTINCT ... subquery), and not do a
redundant unique-ification step.

result for jointypes associated with IN processing.

join conditions in which each OR subclause includes a constraint on
the same relation.  This implements the other useful side-effect of
conversion to CNF format, without its unpleasant side-effects.  As
per pghackers discussion of a few weeks ago.

run the data through cpp, and we know of at least one platform where
unusual cpp behavior breaks the process.  So remove the cpp step,
and make consequent simplifications.

be cast to unsigned char.  We have learned this the hard way before.

teaching the latter to accept either RestrictInfo nodes or bare
clause expressions; and cache the selectivity result in the RestrictInfo
node when possible.  This extends the caching behavior of approx_selectivity
to many more contexts, and should reduce duplicate selectivity
calculations.

Problem report on True64 Unix by Nikola Milutinovic.

first time generate an OR indexscan for a two-column index when the WHERE
condition is like 'col1 = foo AND (col2 = bar OR col2 = baz)' --- before,
the OR had to be on the first column of the index or we'd not notice the
possibility of using it.  Some progress towards extracting OR indexscans
from subclauses of an OR that references multiple relations, too, although
this code is #ifdef'd out because it needs more work.

This ensures stdout is kept in sync with messages on stderr.
Per report from Olaf Ferger.

fields: now they are valid whenever the clause is a binary opclause,
not only when it is a potential join clause (there is a new boolean
field canjoin to signal the latter condition).  This lets us avoid
recomputing the relid sets over and over while examining indexes.
Still more work to do to make this as useful as it could be, because
there are places that could use the info but don't have access to the
RestrictInfo node.

LC_CTYPE settings of a database.

required.

just look for common clauses that can be pulled out of ORs.  Per recent
discussion, extracting common clauses seems to be the only really useful
effect of normalization, and if we do it explicitly then we can avoid
cluttering the qual with partially-redundant duplicated expressions, which
was an unpleasant side-effect of the old approach.

number-of-buckets that exceeds the size we actually plan to allow
the hash table to grow to.  Per trouble report from Sean Shanny.

call.  You'd think this would cause some problems, but because of the
way hash_create is coded, the only side-effect was creation of a useless
memory context for the hashtable.

memory contexts belonging to hash tables.  Makes the memory stats printout
a little more useful.

conditions is overkill; set_union() does the job about as well, and
much more efficiently.  Furthermore this avoids assuming that
canonicalize_qual() will check for duplicate clauses at all, which
it may not always do.

showed that for common operator names such as '=', the pallocs done by
this routine occupied a surprisingly large fraction of the total time
for the parser to process an operator.

about whether it is applied before or after eval_const_expressions().
I believe there were some corner cases where the system would fail to
recognize that a partial index is applicable because of the previous
inconsistency.  Store normal rather than 'implicit AND' representations
of constraints and index predicates in the catalogs.
initdb forced due to representation change of constraints/predicates.

could never exceed 30K.  Per report from Andreas Pflug.

PQexecFinish().  Per report from Andreas Pflug.

instruction in the s_lock() wait loop, and use test before test-and-set
in TAS() macro to avoid unnecessary bus traffic.  Patch from Manfred
Spraul, reworked a bit by Tom.

version of a shared library.

index entries.