result relation ... wrong ...

a SubLink with the subplan's targetlist.  This fixes a problem seen with,
for example, a subselect that uses GROUP BY.

thereby guaranteeing wrong results from a rescanned Group node.

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

----------
exec sql begin declare section;
   short s ;
   unsigned short us;
exec sql end   declare section;
exec sql create table test(s smallint, us smallint);
exec sql commit;
s = 1; us =32000;
exec sql insert into test values( :s, :us ) ;  <== error

Error Message: "i4toi2: '-600309759' causes int2 underflow"

Masaaki Sakaida

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