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
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 value is
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
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
would
Maciek Sakrejda wrote:
On Tue, Mar 5, 2013 at 12:03 AM, Albe Laurenz laurenz.a...@wien.gv.at 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
On 03/05/2013 07:23 PM, Tom Lane wrote:
Maciek Sakrejda m.sakre...@gmail.com 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
Daniel Farina wrote:
On Mon, Mar 4, 2013 at 2:27 PM, Maciek Sakrejda m.sakre...@gmail.com wrote:
On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane t...@sss.pgh.pa.us 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
Daniel Farina dan...@heroku.com 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
On 05.03.2013 15:59, Kevin Grittner wrote:
Daniel Farinadan...@heroku.com 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
On Tue, Mar 5, 2013 at 12:03 AM, Albe Laurenz laurenz.a...@wien.gv.at 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
HL == Heikki Linnakangas hlinnakan...@vmware.com 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
Maciek Sakrejda m.sakre...@gmail.com 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
On Tue, Mar 5, 2013 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us 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
Maciek Sakrejda m.sakre...@gmail.com writes:
On Tue, Mar 5, 2013 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us 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
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
On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Mar 4, 2013 at 2:27 PM, Maciek Sakrejda m.sakre...@gmail.com wrote:
On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane t...@sss.pgh.pa.us 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
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
Maciek Sakrejda m.sakre...@gmail.com 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
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
