Alter the signature for encoding conversion functions to declare the
output area as INTERNAL not CSTRING.  This is to prevent people from
calling the functions by hand.  This is a permanent solution for the
back branches but I hope it is just a stopgap for HEAD.

Change tsearch2 to not use the unsafe practice of creating functions
that return INTERNAL without also having INTERNAL arguments.  Since the
functions in question aren't meant to be called by hand anyway, I just
redeclared them to take 'internal' instead of 'text'.  Also add code
to ProcedureCreate() to enforce the restriction, as I should have done
to start with :-(

Fix typos in documentation.

Add FAQ on who controls the project.

Completed:

< * Remove unreferenced table files created by transactions that were
> * -Check for unreferenced table files created by transactions that were

Check the file system on postmaster startup and report any unreferenced
files in the server log.

Heikki Linnakangas

Add some missing "See Also" entries to the domain-related SQL reference
pages. From Robert Treat.

Change SPI functions to use a `long' when specifying the number of tuples
to produce when running the executor. This is consistent with the internal
executor APIs (such as ExecutorRun), which also use a long for this purpose.
It also allows FETCH_ALL to be passed -- since FETCH_ALL is defined as
LONG_MAX, this wouldn't have worked on platforms where int and long are of
different sizes. Per report from Tzahi Fadida.

Change CREATE TYPE to require datatype output and send functions to have
only one argument.  (Per recent discussion, the option to accept multiple
arguments is pretty useless for user-defined types, and would be a likely
source of security holes if it was used.)  Simplify call sites of
output/send functions to not bother passing more than one argument.

Fix incorrect backslashing in regexp example, per Robert Treat.

Mention the actual stored size of NUMERIC values, per David Fetter.

Remove the contents of the src/corba subdirectory: this has been dead code
for a long time.

Change catalog entries for record_out and record_send to show only one
argument, since that's all they are using now.  Adjust type_sanity
regression test so that it will complain if anyone tries to define
multiple-argument output functions in future.

Make record_out and record_send extract type information from the passed
record object itself, rather than relying on a second OID argument to be
correct.  This patch just changes the function behavior and not the
catalogs, so it's OK to back-patch to 8.0.  Will remove the now-redundant
second argument in pg_proc in a separate patch in HEAD only.

Use the standard lock manager to establish priority order when there
is contention for a tuple-level lock.  This solves the problem of a
would-be exclusive locker being starved out by an indefinite succession
of share-lockers.  Per recent discussion with Alvaro.

GCC 4.0 includes a new warning option, -Wformat-literal, that emits
a warning when a variable is used as a format string for printf()
and similar functions (if the variable is derived from untrusted
data, it could include unexpected formatting sequences). This
emits too many warnings to be enabled by default, but it does
flag a few dubious constructs in the Postgres tree. This patch
fixes up the obvious variants: functions that are passed a variable
format string but no additional arguments.

Most of these are harmless (e.g. the ruleutils stuff), but there
is at least one actual bug here: if you create a trigger named
"%sfoo", pg_dump will read uninitialized memory and fail to dump
the trigger correctly.

Fix BCC to not define compiler location.

Update FAQ.

Update replication FAQ.

Christopher Browne

Restructure LOCKTAG as per discussions of a couple months ago.
Essentially, we shoehorn in a lockable-object-type field by taking
a byte away from the lockmethodid, which can surely fit in one byte
instead of two.  This allows less artificial definitions of all the
other fields of LOCKTAG; we can get rid of the special pg_xactlock
pseudo-relation, and also support locks on individual tuples and
general database objects (including shared objects).  None of those
possibilities are actually exploited just yet, however.

I removed pg_xactlock from pg_class, but did not force initdb for
that change.  At this point, relkind 's' (SPECIAL) is unused and
could be removed entirely.

Remove extern from optreset that was just added.

Improve cleanup from win32 client-only build.

Backpatch BCC compile changes to 8.0.X for psql.

This patch fixes a bug in the error message emitted by pg_restore on an
incorrect -F argument: write_msg() expects its first parameter to be a
"module name", not the format string.

Done:

> * -Implement shared row locks and use them in RI triggers

Implement sharable row-level locks, and use them for foreign key references
to eliminate unnecessary deadlocks.  This commit adds SELECT ... FOR SHARE
paralleling SELECT ... FOR UPDATE.  The implementation uses a new SLRU
data structure (managed much like pg_subtrans) to represent multiple-
transaction-ID sets.  When more than one transaction is holding a shared
lock on a particular row, we create a MultiXactId representing that set
of transactions and store its ID in the row's XMAX.  This scheme allows
an effectively unlimited number of row locks, just as we did before,
while not costing any extra overhead except when a shared lock actually
has to be shared.   Still TODO: use the regular lock manager to control
the grant order when multiple backends are waiting for a row lock.

Alvaro Herrera and Tom Lane.

Fix a whitespace problem. From Alvaro Herrera.

Add WAL compression item to TODO.detail.

Add psql \set ON_ERROR_ROLLBACK to allow statements in a transaction to
error without affecting the entire transaction.  Valid values are
"on|interactive|off".

Wording improvement.

Update PAM documentation, per Alvaro.

Mention that PAM requires the user already exist in the database, per
Dick Davies.

On further experimentation, there were still a couple of bugs in
ExpandIndirectionStar() ... and in markTargetListOrigin() too.

Fix ExpandIndirectionStar to handle cases where the expression to be
expanded is of RECORD type, eg
'select (foo).* from (select foo(f1) from t1) ss'
where foo() is a function declared with multiple OUT parameters.

get_expr_result_type probably needs to be able to handle OpExpr as well
as FuncExpr, to cover cases where a function returning tuple is invoked
via an operator.

Update description:

< * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
> * Allow ORDER BY ... LIMIT # to select high/low value without sort or
868c868
<   Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort
>   Right now, if no index exists, ORDER BY ... LIMIT # requires we sort
870a871
>   MIN/MAX already does this, but not for LIMIT > 1.

Re-add item with better description:

> * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
>   index using a sequential scan for highest/lowest values
>
>   Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort
>   all values to return the high/low value.  Instead The idea is to do a
>   sequential scan to find the high/low value, thus avoiding the sort.
>

Fix btree_gist to handle timetz zone correctly per recent changes.

Avoid rechecking lossy operators twice in a bitmap scan plan.

While determining the filter clauses for an index scan (either plain
or bitmap), use pred_test to be a little smarter about cases where a
filter clause is logically unnecessary.  This may be overkill for the
plain indexscan case, but it's definitely useful for OR'd bitmap scans.

Replace slightly klugy create_bitmap_restriction() function with a
more efficient routine in restrictinfo.c (which can make use of
make_restrictinfo_internal).

Add description for concurrent sequential scans:

>   One possible implementation is to start sequential scans from the lowest
>   numbered buffer in the shared cache, and when reaching the end wrap
>   around to the beginning, rather than always starting sequential scans
>   at the start of the table.

Remove support for OR'd indexscans internal to a single IndexScan plan
node, as this behavior is now better done as a bitmap OR indexscan.
This allows considerable simplification in nodeIndexscan.c itself as
well as several planner modules concerned with indexscan plan generation.
Also we can improve the sharing of code between regular and bitmap
indexscans, since they are now working with nigh-identical Plan nodes.

Adjust nodeBitmapIndexscan.c to not keep the index open across calls,
but just to open and close it during MultiExecBitmapIndexScan.  This
avoids acquiring duplicate resources (eg, multiple locks on the same
relation) in a tree with many bitmap scans.  Also, don't bother to
lock the parent heap at all here, since we must be underneath a
BitmapHeapScan node that will be holding a suitable lock.

Actually, nodeBitmapIndexscan.c doesn't need to create a standard
ExprContext at all, since it never evaluates any qual or tlist expressions.

Put back example of using Result node to execute an INSERT.

Update wording:

<   This allows vacuum to reclaim free space without requiring
<   a sequential scan
>   This allows vacuum to target specific pages for possible free space
>   without requiring a sequential scan.

Update wording.

Clean up HTML.

Add replication FAQ item.

Update some comments to use SQL examples rather than QUEL. From Simon
Riggs.

Add line break.

Update book items.

Update VACUUM VERBOSE FSM message, per Tom.

Repair two TIME WITH TIME ZONE bugs found by Dennis Vshivkov.  Comparison
of timetz values misbehaved in --enable-integer-datetime cases, and
EXTRACT(EPOCH) subtracted the zone instead of adding it in all cases.
Backpatch to all supported releases (except --enable-integer-datetime code
does not exist in 7.2).

Remove useless argtype_inherit() code, and make consequent simplifications.
As I pointed out a few days ago, this code has failed to do anything useful
for some time ... and if we did want to revive the capability to select
functions by nearness of inheritance ancestry, this is the wrong place
and way to do it anyway.  The knowledge would need to go into
func_select_candidate() instead.  Perhaps someday someone will be motivated
to do that, but I am not today.

Turns out our existing page size is already optimal in most cases:

< * Research the use of larger page sizes

Item already added to existing 'thread' item:

< * Consider parallel processing a single query
<
<   This would involve using multiple threads or processes to do optimization,
<   sorting, or execution of single query.  The major advantage of such a
<   feature would be to allow multiple CPUs to work together to process a
<   single query.
<

Remove item, not sure what it refers to:

< * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
<   index using a sequential scan for highest/lowest values
<
<   If only one value is needed, there is no need to sort the entire
<   table. Instead a sequential scan could get the matching value.
<

New item:

> * Change WAL to use 32-bit CRC, for performance reasons

Update threading item:

<   Solaris) might benefit from threading.
>   Solaris) might benefit from threading.  Also explore the idea of
>   a single session using multiple threads to execute a query faster.

Done:

< * Improve SMP performance on i386 machines
> * -Improve SMP performance on i386 machines

Remove explicit FreeExprContext calls during plan node shutdown.  The
ExprContexts will be freed anyway when FreeExecutorState() is reached,
and letting that routine do the work is more efficient because it will
automatically free the ExprContexts in reverse creation order.  The
existing coding was effectively freeing them in exactly the worst
possible order, resulting in O(N^2) behavior inside list_delete_ptr,
which becomes highly visible in cases with a few thousand plan nodes.

ExecFreeExprContext is now effectively a no-op and could be removed,
but I left it in place in case we ever want to put it back to use.

Done:

< * Optimize locale to have minimal performance impact when not used

Fix typo:

< * Add ISo INTERVAL handling
> * Add ISO INTERVAL handling

Update VACUUM VERBOSE update, per Alvaro.

Update working of VACUUM VERBOSE.

Make VACUUM VERBOSE FSM output all output in a single INFO output
statement.

Move info about lack of depencency checking in Makefiles to developer's faq.q

Update FAQ by eliminating non-frequent items like large objects and
extending questions.  Update wording of various entries.

Done:

> * -Allow non-bitmap indexes to be combined by creating bitmaps in memory

Update H4 tag to H3 to be consistent with heading levels.

Add item about server-side debugging.

Update FAQ items to point to existing web pages rather than duplication
such information.  Remove MySQL mention.  Move server-side debug item to
developer's FAQ.  Update URLs.

Add comment about checkpoint panic behavior during shutdown, per
suggestion from Qingqing Zhou.

Allow -2147483648 to be treated as an INT4 rather than INT8 constant.
Per discussion with Paul Edwards.

Treat a zero-D array as empty in int_enum(), per Andrew@supernews.

Recent changes got the sense of the notnull bit backwards in the 2.0
protocol output routines.  Mea culpa :-(.  Per report from Kris Jurka.

Define the right-hand input of AT TIME ZONE as a full a_expr instead of
c_expr.  Perhaps the restriction was once needed to avoid bison errors,
but it seems to work just fine now --- and even generates a slightly
smaller state machine.  This change allows examples like
SELECT '13:45'::timetz AT TIME ZONE '-07:00'::interval;
to work without parentheses around the right-hand input.

Update FAQ release number to 8.0.2.

Modify output of VACUUM VERBOSE to be clearer.

int_aggregate's int_enum() doesn't work correctly with arrays that
aren't 1-D, so give an error message instead of failing.  Per report
from Ron Mayer.

Turns out that my recent elimination of the 'redundant' flatten_andors()
code in prepqual.c had a small drawback: the flatten_andors code was
able to cope with deeply nested AND/OR structures (like 10000 ORs in
a row), whereas eval_const_expressions tends to recurse until it
overruns the stack.  Revise eval_const_expressions so that it doesn't
choke on deeply nested ANDs or ORs.

Add documentation stating how to determine if FSM settings are too low
--- look at a database-wide VACUUM VERBOSE.

Teach choose_bitmap_and() to actually be choosy --- that is, try to
make some estimate of which available indexes to AND together, rather
than blindly taking 'em all.  This could probably stand further
improvement, but it seems to do OK in simple tests.

Fix bogus EXPLAIN display of rowcount estimates for BitmapAnd and
BitmapOr nodes.

First cut at planner support for bitmap index scans.  Lots to do yet,
but the code is basically working.  Along the way, rewrite the entire
approach to processing OR index conditions, and make it work in join
cases for the first time ever.  orindxpath.c is now basically obsolete,
but I left it in for the time being to allow easy comparison testing
against the old implementation.

Fix typo:

<   Currently indexes do not have enough tuple tuple visibility
<   information to allow data to be pulled from the index without
<   also accessing the heap.  One way to allow this is to set a bit
<   to index tuples to indicate if a tuple is currently visible to
<   all transactions when the first valid heap lookup happens.  This
<   bit would have to be cleared when a heap tuple is expired.
>   Currently indexes do not have enough tuple visibility information
>   to allow data to be pulled from the index without also accessing
>   the heap.  One way to allow this is to set a bit to index tuples
>   to indicate if a tuple is currently visible to all transactions
>   when the first valid heap lookup happens.  This bit would have to
>   be cleared when a heap tuple is expired.

Typo fix.  Alvaro.

Update URL for TODO list.

Remove pre-7.3 mention that FOR UPDATE can be before LIMIT.

Document that FOR UPDATE and LIMIT together can return fewer rows that
LIMIT specifies, and why.

Clarify that only crypt can't use md5 pg_shadow passwords.

Clarify use of MD5 authentication and pg_shadow encryption.

Rethink original decision to use AND/OR Expr nodes to represent bitmap
logic operations during planning.  Seems cleaner to create two new Path
node types, instead --- this avoids duplication of cost-estimation code.
Also, create an enable_bitmapscan GUC parameter to control use of bitmap
plans.

Updated text for bitmaps:

<   Bitmap indexes index single columns that can be combined with other bitmap
<   indexes to dynamically create a composite index to match a specific query.
<   Each index is a bitmap, and the bitmaps are bitwise AND'ed or OR'ed to be
<   combined.  They can index by tid or can be lossy requiring a scan of the
<   heap page to find matching rows, or perhaps use a mixed solution where
<   tids are recorded for pages with only a few matches and per-page bitmaps
<   are used for more dense pages.  Another idea is to use a 32-bit bitmap
<   for every page and set a bit based on the item number mod(32).

>   This feature allows separate indexes to be ANDed or ORed together.  This
>   is particularly useful for data warehousing applications that need to
>   query the database in an many permutations.  This feature scans an index
>   and creates an in-memory bitmap, and allows that bitmap to be combined
>   with other bitmap created in a similar way.  The bitmap can either index
>   all TIDs, or be lossy, meaning it records just page numbers and each
>   page tuple has to be checked for validity in a separate pass.

Done:

< * Add tool to query pg_stat_* tables and report indexes that aren't needed
<   or tables that might need indexes

Install some slightly realistic cost estimation for bitmap index scans.

Make pg_ctl status do a kill() test to verify that the PID found in
postmaster.pid still represents a live postmaster.

Add note clarifying that indexes that support ordered scans had better
allow clauseless scans.

Don't try to run clauseless index scans on index types that don't support
it.  Per report from Marinos Yannikos.