Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I find that two geometry 'expected' files are now sufficient to cover
>> all the platforms I have available to test. (We'd only need one, if
>> everyone displayed minus zero as '-0', but some platforms print '0'.)
> Judging from t
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
> [ patch for extra_float_digits ]
I've applied this patch along with followup changes to pg_dump (it sets
extra_float_digits to 2 to allow accurate dump/reload) and the geometry
regression test (it sets extra_float_digits to -3).
I find that two ge
"Pedro M. Frazao F. Ferreira" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Evidently. I have the patch and was planning to apply it myself as soon
>> as Pedro does something with the geometry types...
> Its done.
So it is, dunno what I was thinking. Will work on getting it applied.
HI All,
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I am confused about this patch. I don't see extra_float_digits defined
anywhere. Am I missing a patch ?
Probably! :)
The definition of extra_float_digits was made in float.c and the diff was sent
to the list and Tom befor
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am confused about this patch. I don't see extra_float_digits defined
> anywhere. Am I missing a patch?
Evidently. I have the patch and was planning to apply it myself as soon
as Pedro does something with the geometry types...
I am confused about this patch. I don't see extra_float_digits defined
anywhere. Am I missing a patch?
---
Pedro M. Ferreira wrote:
> Pedro M. Ferreira wrote:
> > Tom Lane wrote:
> >> Perhaps P_MAXLEN now needs to be (2*(D
Pedro M. Ferreira wrote:
Tom Lane wrote:
Perhaps P_MAXLEN now needs to be (2*(DBL_DIG+2+7)+1), considering
that we'll allow extra_float_digits to be up to 2. What's it used for?
Yes. I guess so, because it is used in what I think is a memory
allocation function. P_MAXLEN is only used twice:
<
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Curse my slowness, but what's the actual problem being fixed here?
Two things:
* allow pg_dump to accurately dump and restore float quantities (setting
float_extra_digits to 2 during the dump will accomplish this, at least
on systems with re
> > Perhaps P_MAXLEN now needs to be (2*(DBL_DIG+2+7)+1), considering
> > that we'll allow extra_float_digits to be up to 2. What's it used for?
>
> Yes. I guess so, because it is used in what I think is a memory
> allocation function. P_MAXLEN is only used twice:
Curse my slowness, but what's
Tom Lane wrote:
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
Is it ok to remove #define P_MAXDIG DBL_DIG,
change P_MAXLEN to 2*(DBL_DIG+7)+1) and
remove the line 'static int digits8 = P_MAXDIG;' ?
Perhaps P_MAXLEN now needs to be (2*(DBL_DIG+2+7)+1), considering
that we'll allow extra_
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
> Is it ok to remove #define P_MAXDIG DBL_DIG,
> change P_MAXLEN to 2*(DBL_DIG+7)+1) and
> remove the line 'static int digits8 = P_MAXDIG;' ?
Perhaps P_MAXLEN now needs to be (2*(DBL_DIG+2+7)+1), considering
that we'll allow extra_float_digits t
Tom Lane wrote:
Yeah. In fact I'd be inclined to remove the static variable and make
the code match float8out exactly (do "DBL_DIG + extra_float_digits").
P_MAXDIG is only used in the lines below:
#define P_MAXDIG DBL_DIG
#define P_MAXLEN (2*(P_MAXDIG+7)+1)
static int digits8 = P_MAXDIG;
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
> These functions produce output with (for pair_encode):
> sprintf(str, "%.*g,%.*g", digits8, x, digits8, y);
> digits8 is defined as ,
> #define P_MAXDIG DBL_DIG
> static int digits8 = P_MAXDIG;
> I think it would be done the same way as for
Tom Lane wrote:
BTW, did you check to see if this affects the geometric types or not?
I am not sure that they go through float8out; they may need similar
adjustments in their output routines.
In fact they need adjustments.
The *_out routines (in src/backend/utils/adt/geo_ops.c) for the
geomet
Tom Lane wrote:
Looks good, will keep to apply after we branch for 7.4 development.
BTW, did you check to see if this affects the geometric types or not?
I am not sure that they go through float8out; they may need similar
adjustments in their output routines.
Only checked arrays.
I will check
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
> I am attaching the diff's made with diff -u. Sources were from Debian
> source package Version 7.2.1-2woody2.
Looks good, will keep to apply after we branch for 7.4 development.
BTW, did you check to see if this affects the geometric types or not
Tom Lane wrote:
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
>>
If extra_float_digits==-13 and we are outputing a float4 this results in
a negative value for FLT_DIG+extra_float_digits.
You would want to clamp the values passed to %g to not less than 1.
I'd favor code like
int ndig = FLT_D
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think a single setting extra_float_digits would be sufficient.
> Ok. Assuming,
> int extra_float_digits, default 0, min -13, max 2
> If extra_float_digits==-13 and we are outputing a float4 this results in
> a negative value
Tom Lane wrote:
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
int extra_float4_digits, default 0, min -4, max 2
int extra_float8_digits, defualt 0, min -13, max 2
I think a single setting extra_float_digits would be sufficient.
Ok. Assuming,
int extra_float_digits, default 0, min -13, ma
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
> int extra_float4_digits, default 0, min -4, max 2
> int extra_float8_digits, defualt 0, min -13, max 2
I think a single setting extra_float_digits would be sufficient.
> Also, if we concluded that there is a need of 2 more digits, should'nt
> thi
20 matches
Mail list logo
