On Mon, Apr 21, 2008 at 7:10 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Note that we are already exercising both ends of the
> float8-byval option, so probably only --disable-float4-byval
> is very interesting to test explicitly.
I'll set up a new animal with --disable-float4-byval this week.
-
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> On Mon, Apr 21, 2008 at 2:28 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Applied with revisions --- mostly, supporting configure-time control
>> over whether pass-by-value is used.
> Do we need buildfarm coverage of these options?
Wouldn't hurt, I gue
On Mon, Apr 21, 2008 at 2:28 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Applied with revisions --- mostly, supporting configure-time control
> over whether pass-by-value is used.
Do we need buildfarm coverage of these options?
--
Guillaume
--
Sent via pgsql-patches mailing list (pgsql-patches
Zoltan Boszormenyi <[EMAIL PROTECTED]> 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
> (patc
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
That looks suspiciously locale-ish; what locale are you running PG in?
hu_HU.UTF-8
Ah, and I'll bet zs sorts after zy in hu_HU.
Yes, "zs" is a double letter that sorts after "z" in general un hu_HU.
The q
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
>> That looks suspiciously locale-ish; what locale are you running PG in?
> hu_HU.UTF-8
Ah, and I'll bet zs sorts after zy in hu_HU.
The query is already doing an ORDER BY, so it's not at fault. I think
the only thing we could do about this is add
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> With contrib/seg also adjusted to use float4 instead of float32, and
> thus the last usage of float32 gone, I am now wondering if it would be a
> good idea to remove the float32 and float32data definitions in c.h.
Well, there might still be some referen
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
Both --enable and --disable-float4-byval produced only this regression,
but it seems to be a tuple order difference.
That looks suspiciously locale-ish; what locale are you running PG in?
regards, to
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Both --enable and --disable-float4-byval produced only this regression,
> but it seems to be a tuple order difference.
That looks suspiciously locale-ish; what locale are you running PG in?
regards, tom lane
--
Sent via pg
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
So I think we really do need to offer that compile-time option.
Failing to do so will be tantamount to desupporting v0 functions
altogether, which I don't think we're prepared to do.
I have asked the Cybertec guys for a patch. Si
Zoltan Boszormenyi wrote:
>>> So I think we really do need to offer that compile-time option.
>>> Failing to do so will be tantamount to desupporting v0 functions
>>> altogether, which I don't think we're prepared to do.
>>>
>>
>> I have asked the Cybertec guys for a patch. Since it's basica
Alvaro Herrera írta:
Tom Lane wrote:
Specifically, I think what you missed is that on some platforms C
functions pass or return float values differently from similar-sized
integer or pointer values (typically, the float values get passed in
floating-point registers).
Argh ... I would
Tom Lane wrote:
> Specifically, I think what you missed is that on some platforms C
> functions pass or return float values differently from similar-sized
> integer or pointer values (typically, the float values get passed in
> floating-point registers).
Argh ... I would have certainly missed tha
Tom Lane <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Since they're v0, they'd have to explicitly know about the pass-by-ref
>>> status of float4.
>> Well, the previous code was doing some pallocs, and the new code is not:
>> http://anoncvs.postgr
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Since they're v0, they'd have to explicitly know about the pass-by-ref
>> status of float4.
> Well, the previous code was doing some pallocs, and the new code is not:
> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/seg/seg.c.
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I assume this is just some dumb portability mistake on my part ... or
> > perhaps the fact that the functions are still using v0 fmgr convention?
>
> Since they're v0, they'd have to explicitly know about the pass-by-ref
> status of
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I assume this is just some dumb portability mistake on my part ... or
> perhaps the fact that the functions are still using v0 fmgr convention?
Since they're v0, they'd have to explicitly know about the pass-by-ref
status of float4.
Did this patch incl
Alvaro Herrera wrote:
> With contrib/seg also adjusted to use float4 instead of float32, and
> thus the last usage of float32 gone, I am now wondering if it would be a
> good idea to remove the float32 and float32data definitions in c.h.
Ok, the buildfarm is going yellow over this change. On "ca
Zoltan Boszormenyi wrote:
> - float4 conversion is risk free (patch #1)
I applied this #1 patch. It needed some further adjustments; in
particular contrib/btree_gist regression check was crashing, and
utils/fmgr/README needed updating.
With contrib/seg also adjusted to use float4 instead of flo
Hi,
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 on
20 matches
Mail list logo
