| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Zoltan Boszormenyi <zb(at)cybertec(dot)at> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-patches(at)postgresql(dot)org, Hans-Juergen Schoenig <hs(at)cybertec(dot)at>, Magnus Hagander <magnus(at)hagander(dot)net> |
| Subject: | Re: float4/float8/int64 passed by value with tsearch fixup |
| Date: | 2008-04-21 00:28:19 |
| Message-ID: | 9738.1208737699@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Zoltan Boszormenyi <zb(at)cybertec(dot)at> writes:
> I tried to split the previous patch up to see where the tsearch regression
> comes from. So, it turned out that:
> - float4 conversion is risk free (patch #1)
> - float8 conversion is okay, too, if coupled with time[stamp[tz]] conversion
> (patch #2) but with int64 timestamps enabled, the next one is also
> needed:
> - int64 conversion (patch #3) is mostly okay but it is the one that's
> causing
> the tsearch regression
Applied with revisions --- mostly, supporting configure-time control
over whether pass-by-value is used.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-04-21 00:36:46 | Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 |
| Previous Message | Peter Eisentraut | 2008-04-20 18:01:22 | Re: Coding standards |