Thanks for Vadim for fixes.

yyerror ones from bison. It also includes a few 'enhancements' to
the C programming style (which are, of course, personal).

The other patch removes the compilation of backend/lib/qsort.c, as
qsort() is a standard function in stdlib.h and can be used any
where else (and it is). It was only used in
backend/optimizer/geqo/geqo_pool.c, backend/optimizer/path/predmig.c,
and backend/storage/page/bufpage.c

> > Some or all of these changes might not be appropriate for v6.3,
since we > > are in beta testing and since they do not affect the
current functionality.  > > For those cases, how about submitting
patches based on the final v6.3 > > release?

There's more to come. Please review these patches. I ran the
regression tests and they only failed where this was expected
(random, geo, etc).

Cheers,

Jeroen

	return, not a slot returned from access method (they have
	different TupleDesc and MergeJoin node was broken).
nodeIndexscan.c: index_markpos()/index_restrpos() call index-specific
	mark/restr funcs and are in use now (instead of
	IndexScanMarkPosition()/ExecIndexRestrPos()).

ExecReScan for nodeAgg, nodeHash, nodeHashjoin, nodeNestloop and nodeResult.
Fixed ExecReScan for nodeMaterial.
Get rid of #ifdef INDEXSCAN_PATCH.
Get rid of ExecMarkPos and ExecRestrPos in nodeNestloop.

Another PGINDENT run that changes variable indenting and case label indenting.  Also static variable indenting.

Subject: [HACKERS] linux/alpha patches

These patches lay the groundwork for a Linux/Alpha port.  The port doesn't
actually work unless you tweak the linker to put all the pointers in the
first 32 bits of the address space, but it's at least a start.  It
implements the test-and-set instruction in Alpha assembly, and also fixes
a lot of pointer-to-integer conversions, which is probably good anyway.

ExecInitIndexScan now works with operands of Param type and
(!!!) postquel_execute() now substitutes param values
before calling postquel_start().

I found another bug in btree index.  Looking at the code it seems that NULL
keys are never used to build or scan a btree index (see the explain commands
in the example).  However this is not the case when a null key is retrieved
in an outer loop of a join select and used in an index scan of an inner loop.
This bug causes at least three kinds of problems:

1)  the backend crashes when it tries to compare a text string with a null.

2)  it is not possible to find tuples with null keys in a join.

3)  null is considered equal to 0 when the datum is passed by value, see
    the last query.

Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>