that contain null fields.  Old code would produce erratic sort results
because comparisons of tuples containing nulls could produce inconsistent
answers.

> the DTK_MICROSEC case is just like the DTK_MILLISEC case.
> I think this is wrong and it ought to look like
>         fsec = rint(fsec * 1000000) / 1000000;
> no?

Tom Lane.

"HAS_LONG_LONG" is defined based on the assumption that
strtol() would return ERANGE if a platform does not support
64-bit integers. In current PostgreSQL 6.5 (and 6.4.2)
distribution, "HAS_LONG_LONG" is defined only if platform
is "alpha". (See include/port/alpha.h) I think the int4
range check should apply to linux_alpha as well. (I have
not tested yet but I guess this might be applicable to
newer Linux/i386 distributions which includes new GCC which
implements long int as 64-bit int.)

functions, in order to work around oversight in 6.5 release: rtree
index functions haven't got any.  Mea culpa ...

this one could be useful for people experiencing out-of-memory crashes while
executing queries which retrieve or use a very large number of tuples.

The problem happens when storage is allocated for functions results used in
a large query, for example:

  select upper(name) from big_table;
  select big_table.array[1] from big_table;
  select count(upper(name)) from big_table;

This patch is a dirty hack that fixes the out-of-memory problem for the most
common cases, like the above ones. It is not the final solution for the
problem but it can work for some people, so I'm posting it.

The patch should be safe because all changes are under #ifdef. Furthermore
the feature can be enabled or disabled at runtime by the `free_tuple_memory'
options in the pg_options file. The option is disabled by default and must
be explicitly enabled at runtime to have any effect.

To enable the patch add the follwing line to Makefile.custom:

CUSTOM_COPT += -DFREE_TUPLE_MEMORY

To enable the option at runtime add the following line to pg_option:

free_tuple_memory=1

Massimo

a non-leading % would be put into the >=/<= patterns.  Also, repair
longstanding confusion about whether %% means a literal %%.  The SQL92
doesn't say any such thing, and textlike() knows that, but gram.y didn't.

trace.patch (compilation error)

        the gettimeofday doesn't compile under Linux with glibc2 because
        the DST_NONE constant is no more defined. It seems that this code
        (written by me) has always be wrong but for some reason working.

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

in the same transaction that created it.

Jan

198.68.123.0/27 the same when indexing them.

D'Arcy

all fields that should be set).  Add a MoveToFront primitive to speed up
one of the hotspots in SearchSysCache.

in an index doesn't have a restriction selectivity estimator.

right circumstances it would leave old and new bucket headers pointing to
the same list of records.