per-column options for btree indexes.  The planner's support for this is still
pretty rudimentary; it does not yet know how to plan mergejoins with
nondefault ordering options.  The documentation is pretty rudimentary, too.
I'll work on improving that stuff later.

Note incompatible change from prior behavior: ORDER BY ... USING will now be
rejected if the operator is not a less-than or greater-than member of some
btree opclass.  This prevents less-than-sane behavior if an operator that
doesn't actually define a proper sort ordering is selected.

< * %Allow the identifier length to be increased via a configure option

< * Improve the MONEY data type
> * -Make 64-bit version of the MONEY data type
> * Add locale-aware MONEY type, and support multiple currencies
<   Change the MONEY data type to use DECIMAL internally, with special
<   locale-aware output formatting.
<   http://archives.postgresql.org/pgsql-hackers/2006-09/msg01107.php

> * -Allow user-defined types to accept 'typmod' parameters

>
> * Make consistent use of long/short command options --- pg_ctl needs
>   long ones, pg_config doesn't have short ones, postgres doesn't have
>   enough long ones, etc.

> 	o Consider parsing the -c string into individual queries so each
> 	  is run in its own transaction
>
> 	o Consider disallowing multiple queries in PQexec() as an
> 	  additional barrier to SQL injection attacks

< * Allow CREATE INDEX to take an additional parameter for use with
<   special index types

< * Allow inherited tables to inherit index, UNIQUE constraint, and primary
<   key, foreign key
< * UNIQUE INDEX on base column not honored on INSERTs/UPDATEs from
<   inherited table:  INSERT INTO inherit_table (unique_index_col) VALUES
<   (dup) should fail
<
<   The main difficulty with this item is the problem of creating an index
<   that can span more than one table.
<
< * Allow SELECT ... FOR UPDATE on inherited tables
> * Inheritance
>
> 	o Allow inherited tables to inherit indexes, UNIQUE constraints,
> 	  and primary/foreign keys
> 	o Honor UNIQUE INDEX on base column in INSERTs/UPDATEs
> 	  on inherited table, e.g.  INSERT INTO inherit_table
> 	  (unique_index_col) VALUES (dup) should fail
>
> 	  The main difficulty with this item is the problem of
> 	  creating an index that can span multiple tables.
>
> 	o Allow SELECT ... FOR UPDATE on inherited tables
>
>
>

> * -Allow the pg_xlog directory location to be specified during initdb

Euler Taveira de Oliveira

back-stamped for this.

Call setrlimit if possible in pg_regress to allow core file generation, and provide a switch for similar behaviour in pg_ctl.

an optarg).  Add some comments noting that code in three different files has
to be kept in sync.  Fix erroneous description of -S switch (it sets work_mem
not silent_mode), and do some light copy-editing elsewhere in postgres-ref.

about typmod representation for standard types out into type-specific
typmod I/O functions.  Teodor Sigaev, with some editorialization by
Tom Lane.

>   http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php

< * Add a GUC to control whether BEGIN inside a transcation should abort
<   the transaction.

for use with constraint exclusion.  We can prove those cases now...

< * Move some /contrib modules out to their own project sites
<
<   Particularly, move GPL-licensed /contrib/userlock and
<   /contrib/dbmirror/clean_pending.pl.
<

remove long-obsolete statement that there isn't a check for infinite
recursion in view rules.

the XmlExpr code in various lists, use a representation that has some hope
of reverse-listing correctly (though it's still a de-escaping function
shy of correctness), generally try to make it look more like Postgres
coding conventions.

and UPDATE are clearly covered by the term.

rather than being disallowed.

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.