pointer type when it is not necessary to do so.

For future reference, casting NULL to a pointer type is only necessary
when (a) invoking a function AND either (b) the function has no prototype
OR (c) the function is a varargs function.

it in the same file as the 'List' node.

> 	o Allow parameters to be specified by name and type during definition

Dennis Bjorklund's original patch for function parameter names, but
there's still plenty left to do (documentation for instance...)

> 	o -Allow parameters to be specified by name and type during definition

parameters to be declared with names.  pg_proc has a column to store
names, and CREATE FUNCTION can insert data into it, but that's all as
yet.  I need to do more work on the pg_dump and plpgsql portions of the
patch before committing those, but I thought I'd get the bulky changes
in before the tree drifts under me.
initdb forced due to pg_proc change.

BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to
closely mimic (the soon to be provided) Win32 CreateProcess equivalent
calls.

Claudio Natoli

> * -Have psql \dn show only visible temp schemas using current_schemas()

     - Update comment in IsReservedName() to the present day

     - Improve some variable & function names in commands/vacuum.c. I
       was planning to rewrite this to avoid lappend(), but since I
       still intend to do the list rewrite, there's no need for that.

     - Update some smgr comments which seemed to imply that we still
       forced all dirty pages to disk at commit-time.

     - Replace some #ifdef DIAGNOSTIC code with assertions.

     - Make the distinction between OS-level file descriptors and
       virtual file descriptors a little clearer in a few comments

     - Other minor comment improvements in the smgr code

backend.

hide it behind #ifdef WAL_DEBUG blocks.

regular qpqual ('filter condition'), add special-purpose code to
nodeIndexscan.c to recheck them.  This ends being almost no net addition
of code, because the removal of planner code balances out the extra
executor code, but it is significantly more efficient when a lossy
operator is involved in an OR indexscan.  The old implementation had
to recheck the entire indexqual in such cases.

with index qual clauses in the Path representation.  This saves a little
work during createplan and (probably more importantly) allows reuse of
cached selectivity estimates during indexscan planning.  Also fix latent
bug: wrong plan would have been generated for a 'special operator' used
in a nestloop-inner-indexscan join qual, because the special operator
would not have gotten into the list of quals to recheck.  This bug is
only latent because at present the special-operator code could never
trigger on a join qual, but sooner or later someone will want to do it.

readability and for the sake of consistency with the rest of analyze.c

have WAL, outer joins, and TOAST.

known unique (eg, it is a SELECT DISTINCT ... subquery), and not do a
redundant unique-ification step.

result for jointypes associated with IN processing.

join conditions in which each OR subclause includes a constraint on
the same relation.  This implements the other useful side-effect of
conversion to CNF format, without its unpleasant side-effects.  As
per pghackers discussion of a few weeks ago.

run the data through cpp, and we know of at least one platform where
unusual cpp behavior breaks the process.  So remove the cpp step,
and make consequent simplifications.

be cast to unsigned char.  We have learned this the hard way before.

teaching the latter to accept either RestrictInfo nodes or bare
clause expressions; and cache the selectivity result in the RestrictInfo
node when possible.  This extends the caching behavior of approx_selectivity
to many more contexts, and should reduce duplicate selectivity
calculations.

Problem report on True64 Unix by Nikola Milutinovic.

first time generate an OR indexscan for a two-column index when the WHERE
condition is like 'col1 = foo AND (col2 = bar OR col2 = baz)' --- before,
the OR had to be on the first column of the index or we'd not notice the
possibility of using it.  Some progress towards extracting OR indexscans
from subclauses of an OR that references multiple relations, too, although
this code is #ifdef'd out because it needs more work.

This ensures stdout is kept in sync with messages on stderr.
Per report from Olaf Ferger.

fields: now they are valid whenever the clause is a binary opclause,
not only when it is a potential join clause (there is a new boolean
field canjoin to signal the latter condition).  This lets us avoid
recomputing the relid sets over and over while examining indexes.
Still more work to do to make this as useful as it could be, because
there are places that could use the info but don't have access to the
RestrictInfo node.