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.

ExprContext at all, since it never evaluates any qual or tlist expressions.

<   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.

Riggs.

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).

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.

< * Research the use of larger page sizes

< * 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.
<

< * 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.
<

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

<   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.

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

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.

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

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

statement.

extending questions.  Update wording of various entries.

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

such information.  Remove MySQL mention.  Move server-side debug item to
developer's FAQ.  Update URLs.

suggestion from Qingqing Zhou.

Per discussion with Paul Edwards.

protocol output routines.  Mea culpa :-(.  Per report from Kris Jurka.

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.

aren't 1-D, so give an error message instead of failing.  Per report
from Ron Mayer.

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.