initdb/regression tests pass.

tests pass.

lookup info in the relcache for index access method support functions.
This makes a huge difference for dynamically loaded support functions,
and should save a few cycles even for built-in ones.  Also tweak dfmgr.c
so that load_external_function is called only once, not twice, when
doing fmgr_info for a dynamically loaded function.  All per performance
gripe from Teodor Sigaev, 5-Oct-01.

for haskeytype).  Update GiST contrib modules too.  Add linear-time split
algorithm for R-tree GiST opclass.
From Oleg Bartunov and Teodor Sigaev.

pgsql-hackers.  pg_opclass now has a row for each opclass supported by each
index AM, not a row for each opclass name.  This allows pg_opclass to show
directly whether an AM supports an opclass, and furthermore makes it possible
to store additional information about an opclass that might be AM-dependent.
pg_opclass and pg_amop now store "lossy" and "haskeytype" information that we
previously expected the user to remember to provide in CREATE INDEX commands.
Lossiness is no longer an index-level property, but is associated with the
use of a particular operator in a particular index opclass.

Along the way, IndexSupportInitialize now uses the syscaches to retrieve
pg_amop and pg_amproc entries.  I find this reduces backend launch time by
about ten percent, at the cost of a couple more special cases in catcache.c's
IndexScanOK.

Initial work by Oleg Bartunov and Teodor Sigaev, further hacking by Tom Lane.

initdb forced.

   (as proposed in http://fts.postgresql.org/db/mw/msg.html?mid=1028327)

2. support for 'pass-by-value' arguments - to test this
   we used special opclass for int4 with values in range [0-2^15]
   More testing will be done after resolving problem with
   index_formtuple and implementation of B-tree using GiST

3. small patch to contrib modules (seg,cube,rtree_gist,intarray) -
   mark functions as 'isstrict' where needed.

Oleg Bartunov

per previous discussion on pghackers.  Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc.  (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.)  The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method.  I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions.  Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.

Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).

Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error.  We discovered this need long
ago for btree, but missed the other guys.

Oh, one more thing: concurrent VACUUM is now the default.

having non-gcc compilers spit up.

and Teodor Sigaev).  Declare key values as Datum where appropriate,
rather than char* (Tom Lane).

number of strategies supported by an index AM.  Add missing copyright
notices and CVS $Header$ markers to GIST source files.

with many NULLs ( inserting of NULL into indexed field cause
ERROR: MemoryContextAlloc: invalid request size)
As a workaround 'vacuum analyze' could be used.

This patch resolves the problem, please upply to 7.1.1 sources and
current cvs tree.

Oleg Bartunov

a separate statement (though it can still be invoked as part of VACUUM, too).
pg_statistic redesigned to be more flexible about what statistics are
stored.  ANALYZE now collects a list of several of the most common values,
not just one, plus a histogram (not just the min and max values).  Random
sampling is used to make the process reasonably fast even on very large
tables.  The number of values and histogram bins collected is now
user-settable via an ALTER TABLE command.

There is more still to do; the new stats are not being used everywhere
they could be in the planner.  But the remaining changes for this project
should be localized, and the behavior is already better than before.

A not-very-related change is that sorting now makes use of btree comparison
routines if it can find one, rather than invoking '<' twice.

succeeds or not.  Revise rtree page split algorithm to take care about
making a feasible split --- ie, will the incoming tuple actually fit?
Failure to make a feasible split, combined with failure to notice the
failure, account for Jim Stone's recent bug report.  I suspect that
hash and gist indices may have the same type of bug, but at least now
we'll get error messages rather than silent failures if so.  Also clean
up rtree code to use Datum rather than char* where appropriate.

allocated by plan nodes are not leaked at end of query.  This doesn't
really matter for normal queries, but it sure does for queries invoked
repetitively inside SQL functions.  Clean up some other grotty code
associated with tupdescs, and fix a few other memory leaks exposed by
tests with simple SQL functions.

New feature:
   1. Support of variable size keys - new algorithm of insertion to tree
      (GLI - gist layrered insertion). Previous algorithm was implemented
      as described in paper by Joseph M. Hellerstein et.al
      "Generalized Search Trees for Database Systems".  This (old)
      algorithm was not suitable for variable size keys and could be
      not effective ( walking up-down ) in case of multiple levels split
Bug fixed:
   1. fixed bug in gistPageAddItem - key values were written to disk
      uncompressed. This caused failure if decompression function
      does real job.
   2. NULLs handling - we keep NULLs in tree. Right way is to remove them,
      but we don't know how to inform vacuum about index statistics. This is
      just cosmetic warning message (like in case with R-Tree),
      but I'm not sure how to recognize real problem if we remove NULLs
      and suppress this warning as Tom suggested.
   3. various memory leaks

This work was done by Teodor Sigaev (teodor@stack.net) and
Oleg Bartunov (oleg@sai.msu.su).

maintained for each cache entry.  A cache entry will not be freed until
the matching ReleaseSysCache call has been executed.  This eliminates
worries about cache entries getting dropped while still in use.  See
my posting to pg-hackers of even date for more info.

(WAL logging for this is not done yet, however.)  Clean up a number of really
crufty things that are no longer needed now that DROP behaves nicely.  Make
temp table mapper do the right things when drop or rename affecting a temp
table is rolled back.  Also, remove "relation modified while in use" error
check, in favor of locking tables at first reference and holding that lock
throughout the statement.

pass-by-ref data types --- eg, an index on lower(textfield) --- no longer
leak memory during index creation or update.  Clean up a lot of redundant
code ... did you know that copy, vacuum, truncate, reindex, extend index,
and bootstrap each basically duplicated the main executor's logic for
extracting information about an index and preparing index entries?
Functional indexes should be a little faster now too, due to removal
of repeated function lookups.
CREATE INDEX 'opt_type' clause is deimplemented by these changes,
but I haven't removed it from the parser yet (need to merge with
Thomas' latest change set first).

memory contexts.  Currently, only leaks in expressions executed as
quals or projections are handled.  Clean up some old dead cruft in
executor while at it --- unused fields in state nodes, that sort of thing.

    WARNING: This is actually broken - we have self-deadlocks
	         due to concurrent changes in buffer management.
			 Vadim and me are working on it.

Jan

passing the index-is-unique flag to index build routines (duh! ...
why wasn't it done this way to begin with?).  Aside from eliminating
an eyesore, this should save a few milliseconds in btree index creation
because a full scan of pg_index is not needed any more.

--- ie, they're only called for side-effects.  Add a PG_RETURN_VOID()
macro and use it where appropriate.  This probably doesn't change the
machine code by a single bit ... it's just for documentation.

functions that take pass-by-value datatypes.  Should be ready for
port testing ...

fmgr_faddr() in favor of new-style calls.  Lots of cleanup of
sloppy casts to use XXXGetDatum and DatumGetXXX ...

running gcc and HP's cc with warnings cranked way up.  Signed vs unsigned
comparisons, routines declared static and then defined not-static,
that kind of thing.  Tedious, but perhaps useful...

from a constraint condition does not violate the constraint (cf. discussion
on pghackers 12/9/99).  Implemented by adding a parameter to ExecQual,
specifying whether to return TRUE or FALSE when the qual result is
really NULL in three-valued boolean logic.  Currently, ExecRelCheck is
the only caller that asks for TRUE, but if we find any other places that
have the wrong response to NULL, it'll be easy to fix them.

where necessary --- several of them didn't really need it, though.
tqual-checking macros simplified accordingly.

Fewer calls to nameout.

Better use of RelationGetRelationName.