Abhijit Menon-Sen escribió:
> At 2013-06-24 10:16:33 +, laurenz.a...@wien.gv.at wrote:
> >
> > What do you think of the attached version?
>
> I'm not exactly fond of it, but I can't come up with a better version
> either. It's slightly better if "but may not accurately represent the
> stored v
At 2013-06-24 10:16:33 +, laurenz.a...@wien.gv.at wrote:
>
> What do you think of the attached version?
I'm not exactly fond of it, but I can't come up with a better version
either. It's slightly better if "but may not accurately represent the
stored value" is removed.
Does anyone else have s
Abhijit Menon-Sen wrote:
> Sorry to nitpick, but I don't like that either, on the grounds that if I
> had been in Tom Duffey's place, this addition to the docs wouldn't help
> me to understand and resolve the problem.
>
> I'm not entirely convinced that any brief mention of extra_float_digits
> wo
At 2013-03-06 10:04:25 +, laurenz.a...@wien.gv.at wrote:
>
> How about this elaboration?
Sorry to nitpick, but I don't like that either, on the grounds that if I
had been in Tom Duffey's place, this addition to the docs wouldn't help
me to understand and resolve the problem.
I'm not entirely
On 03/05/2013 07:23 PM, Tom Lane wrote:
Maciek Sakrejda writes:
Thank you: I think this is what I was missing, and what wasn't clear
from the proposed doc patch. But then how can pg_dump assume that it's
always safe to set extra_float_digits = 3?
It's been proven (don't have a link handy, but
Maciek Sakrejda wrote:
> On Tue, Mar 5, 2013 at 12:03 AM, Albe Laurenz wrote:
>> I don't think that it is about looking nice.
>> C doesn't promise you more than FLT_DIG or DBL_DIG digits of
>> precision, so PostgreSQL cannot either.
>>
>> If you allow more, that would mean that if you store the sa
This conversation has moved beyond my ability to be useful but I want to remind
everyone of my original issues in case it helps you improve the docs:
1) Data shown in psql did not match data retrieved by JDBC. I had to debug
pretty deep into the JDBC code to confirm that a value I was staring at
Maciek Sakrejda writes:
> On Tue, Mar 5, 2013 at 10:23 AM, Tom Lane wrote:
>> Basically, the default behavior is tuned to the expectations of people
>> who think that what they put in is what they should get back, ie we
>> don't want the system doing this by default:
>>
>> regression=# set extra
On Tue, Mar 5, 2013 at 10:23 AM, Tom Lane wrote:
>> Why the discrepancy between
>> default behavior and what pg_dump gets?
>
> Basically, the default behavior is tuned to the expectations of people
> who think that what they put in is what they should get back, ie we
> don't want the system doing
Maciek Sakrejda writes:
> Thank you: I think this is what I was missing, and what wasn't clear
> from the proposed doc patch. But then how can pg_dump assume that it's
> always safe to set extra_float_digits = 3?
It's been proven (don't have a link handy, but the paper is at least
a dozen years o
> "HL" == Heikki Linnakangas writes:
HL> It would be nice to have a base-2 text format to represent floats.
HL> It wouldn't be as human-friendly as base-10, but it could be used
HL> when you don't want to lose precision. pg_dump in particular.
hexidecimal notation for floats exists. The pri
On Tue, Mar 5, 2013 at 12:03 AM, Albe Laurenz wrote:
> I don't think that it is about looking nice.
> C doesn't promise you more than FLT_DIG or DBL_DIG digits of
> precision, so PostgreSQL cannot either.
>
> If you allow more, that would mean that if you store the same
> number on different platf
On 05.03.2013 15:59, Kevin Grittner wrote:
Daniel Farina wrote:
This kind of change may have many practical problems that may
make it un-pragmatic to alter at this time (considering the
workaround is to set the extra float digits), but I can't quite
grasp the rationale for "well, the only prog
Daniel Farina wrote:
> This kind of change may have many practical problems that may
> make it un-pragmatic to alter at this time (considering the
> workaround is to set the extra float digits), but I can't quite
> grasp the rationale for "well, the only program that cares about
> the most precis
Daniel Farina wrote:
> On Mon, Mar 4, 2013 at 2:27 PM, Maciek Sakrejda wrote:
>> On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane wrote:
>>> The real difficulty is that there may be more than one storable value
>>> that corresponds to "1.23456" to six decimal digits. To be certain that
>>> we can reprod
On Mon, Mar 4, 2013 at 2:27 PM, Maciek Sakrejda wrote:
> On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane wrote:
>> The real difficulty is that there may be more than one storable value
>> that corresponds to "1.23456" to six decimal digits. To be certain that
>> we can reproduce the stored value unique
On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane wrote:
> The real difficulty is that there may be more than one storable value
> that corresponds to "1.23456" to six decimal digits. To be certain that
> we can reproduce the stored value uniquely, we have to err in the other
> direction, and print *more*
Maciek Sakrejda writes:
> [ a bunch of questions that boil down to: ]
> Isn't full fidelity possible assuming sensible rounding semantics and
> enough characters of precision?
The fundamental issue is that the underlying representation is binary
and so its precision limit doesn't correspond to an
While having more docs around extra_float_digits is a great idea, I
don't think the patch really clarifies much.
(Disclaimer: I honestly have only a vague idea of the reasoning behind
extra_float_digits existing in the first place, but perhaps that means
I'm a good target audience for the doc patc
Tom Duffey wrote (on -general):
> To bring closure to this thread, my whole problem was caused by not knowing
> about the
> extra_float_digits setting. We have a script that uses COPY to transfer a
> subset of rows from a very
> large production table to a test table. The script was not setting
20 matches
Mail list logo
