int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

Hi,

I got around to (almost) finalize the patch. What it does:
- fixes the configure define described in my previous mail
- when the value of HAVE_LONG_INT_64 == 1, the following types
are passed by value: int8, float8, time, timestamp, timestamptz
The time[stamp[tz]] types caused segfaults in the regression test
if their attbyval setting was different from int8/float8, so it's
really needed.
I am not sure there's another type that needs a similat switch, the
type regression
tests are running fine.
- In the HAVE_LONG_INT_64 == 1 case, Int64GetDatum() becomes a
casting macro instead of a function, some others become functions.
The implementation of DatumGetFloat4()/Float4GetDatum()/etc functions may
change into an inline or change internals.
- float4 is now unconditionally passed by value
- the int8inc(), int2_sum() and int4_sum() used pointers directly from
the Datums
for performance, that code path is now commented out, the other code path
is correct for the AggState and !AggState runs and correct every time
and now
because of the passbyval nature of int8, the !AggState version is not
slower
than using the pointer directly.
- removed deprecated DatumGetFloat32/Float32GetDatum/etc macros, they aren't
used anywhere in the core and contrib source.

There is only one regression, in the tsearch tests. Some selects in
tsearch now
return no records but they don't segfault. I couldn't hunt the bug down yet,
not sure I will have time in the near future for that.

Comments welcome.

Best regards,
Zoltán Böszörményi

Zoltan Boszormenyi írta:
> Hi,
>
> I am working on this TODO item:
>
> * Consider allowing 64-bit integers and floats to be passed by value on
> 64-bit platforms
>
> Also change 32-bit floats (float4) to be passed by value at the same
> time.
>
> For genbki.sh, to correctly determine whether HAVE_LONG_INT_64
> is defined, the attached bugfix is needed in the configure.in machinery.
> This way the pg_config.h actually conforms to the comments for
> HAVE_LONG_INT_64 and HAVE_LONG_LONG_INT_64.
>
> Best regards,
> Zoltán Böszörményi
>
> ------------------------------------------------------------------------
>
>

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/