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

From Zoltan Boszormenyi
Subject int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1
Date
Msg-id 47E82229.20600@cybertec.at
Whole thread Raw
In response to Fix HAVE_LONG[_LONG]_INT_64 to really define to 1  (Zoltan Boszormenyi <zb@cybertec.at>)
Responses Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1  (Gregory Stark <stark@enterprisedb.com>)
Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-patches
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/


Attachment

pgsql-patches by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: script binaries renaming
Next
From: Tom Lane
Date:
Subject: Re: script binaries renaming