The newline handling code was, by far, the most complex part of this
patch. While I think it would be nicer to "filter up" past the newline,
I just don't see this as a common need. Large text fields with newlines
are difficult to really view in psql anyway, and they are likely to be
the longe
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
Bryce Nesbitt wrote:
> Bruce Momjian wrote:
> > I don't think you need to do that to get it applied --- there is nothing
> > windows-specific in your code.
> >
> > Is this ready to be applied? Do you want to send a final update or are
> > you still testing?
> >
> Looks good, but I suggest addin
Tom Lane <[EMAIL PROTECTED]> writes:
> BTW, I trolled the contrib files for other v0 functions taking or
> returning float4 or float8. I found seg_size (fixed it) and a whole
> bunch of functions in earthdistance.
Hmm, actually most of the "bunch" are SQL functions, there's only one
that needs fi
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
BTW, I trolled the contrib files for other v0 functions taking or
returning float4 or float8. I found seg_size (fixed it) and a whole
bunch of functions in earthdistance. Those use float8 not float4,
so they are not broken by this patch, but that module will have to
be v1-ified before we can cons
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
Gregory Stark <[EMAIL PROTECTED]> writes:
>> 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 reg
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
13 matches
Mail list logo
