- New functions to create a portal using a prepared/saved
  SPI plan or lookup an existing portal by name.
- Functions to fetch/move from/in portals. Results are placed
  in the usual SPI_processed and SPI_tuptable, so the entire
  set of utility functions can be used to gain attribute access.
- Prepared/saved SPI plans now use their own memory context
  and SPI_freeplan(plan) can remove them.
- Tuple result sets (SPI_tuptable) now uses it's own memory
  context and can be free'd by SPI_freetuptable(tuptab).

Enhancement of PL/pgSQL

- Uses generic named portals internally in FOR ... SELECT
  loops to avoid running out of memory on huge result sets.
- Support for CURSOR and REFCURSOR syntax using the new SPI
  functionality. Cursors used internally only need no explicit
  transaction block. Refcursor variables can be used inside
  of explicit transaction block to pass cursors between main
  application and functions.


Jan

create_index_paths are not immediately discarded, but are available for
subsequent planner work.  This allows avoiding redundant syscache lookups
in several places.  Change interface to operator selectivity estimation
procedures to allow faster and more flexible estimation.
Initdb forced due to change of pg_proc entries for selectivity functions!

initialized FmgrInfo structs linger after elog.

FUNCTION command.  Guard against trying to load a directory.  Update
documentation some.

errors.properties files were being copied.

/*
 *  parse function
 *  This code is confusing because the database can accept
 *  relation.column, column.function, or relation.column.function.
 *  In these cases, funcname is the last parameter, and fargs are
 *  the rest.
 *
 *  It can also be called as func(col) or func(col,col).
 *  In this case, Funcname is the part before parens, and fargs
 *  are the part in parens.
 *
 */
Node *
ParseFuncOrColumn(ParseState *pstate, char *funcname, List *fargs,
                  bool agg_star, bool agg_distinct,
                  int precedence)

Jan

aggregate seems uniquely fragile, because it's the only one with an
agginitval that's at all likely to change in format.

specification of username (like in psql).  pg_dumpall now works with
password authentication.

library extension.

there is a brace on the line above it.

(1.22) of interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java.  That
change removed a line that set the variable s to the value of the
stringbuffer.   This fix changes the following if checks to check the
length of the stringbuffer instead of s, since s no longer contains the
string the if conditions are expecting.

The bug manifests itself in getTimestamp() loosing the timezone
information of timestamps selected from the database, thereby causing
the time to be incorrect.

Barry Lind

Here's what I came up with. The biggest difference api between JDK1.x and
later versions is the support for collections. The problem was with the
Vector class; in jdk1.x there is no method called add, so I changed the
calls to addElement. Also no addAll, so I rewrote the method slightly to not
require addAll. While reviewing this I notices some System.out.println
statements that weren't commented out. So I commented them out in both
versions.

The upshot of all of this is that I have clean compile, but no idea if the
code works ;(

Dave Cramer

2) Repair broken SQLStatistics().

library code.  Tweak progress messages to include elapsed real time,
not only CPU time.

PageGetFreeSpace() was being called while not holding the buffer lock, which
not only could yield a garbage answer, but even if it's the right answer there
might be less space available after we reacquire the buffer lock.

Also repair potential deadlock introduced by my recent performance improvement
in RelationGetBufferForTuple(): it was possible for two heap_updates to try to
lock two buffers in opposite orders.  The fix creates a global rule that
buffers of a single heap relation should be locked in decreasing block number
order.  Currently, this only applies to heap_update; VACUUM can get away with
ignoring the rule since it holds exclusive lock on the whole relation anyway.
However, if we try to implement a VACUUM that can run in parallel with other
transactions, VACUUM will also have to obey the lock order rule.