Re: Re: 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 Re: Re: 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 47E91686.6040800@cybertec.at
Whole thread Raw
In response to Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses float4/float8/int64 passed by value with tsearch fixup  (Zoltan Boszormenyi <zb@cybertec.at>)
List pgsql-patches
Alvaro Herrera írta:
> I don't think
>     my $int64passbyval = "(?($real64 = 1)t|f)";
>
> works.  Perhaps
>
>     my $int64passbyval = $real64 ? 't' : 'f';
>

Thanks. Modified patch attached.

Stupid question follows. Now that float4 is passed by value
unconditionally, is it worth modifying the *penalty() functions
in GIST/TSearch to just use PG_RETURN_FLOAT4()?
Or the implicit "modify the float4 value at the caller site and
return the same pointer I got as 3rd parameter" is an internal API
set in stone? Modifying them to have only 2 parameters
(the 3rd one was an implicit OUT parameter anyway) and
omitting the pointer dereference might give a small speedup.

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


Attachment

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1
Next
From: Bruce Momjian
Date:
Subject: Re: pg_dump -i wording