On Wed, Apr 1, 2015 at 11:48:37AM -0400, Bruce Momjian wrote:
This should return something like 16.000... (per Oracle
output at the URL above, float4 has 6 significant digits on my compiler)
but I can't seem to figure how to get printf() to round non-fractional
parts. I am afraid
On Tue, Mar 24, 2015 at 09:47:56AM -0400, Noah Misch wrote:
On Sun, Mar 22, 2015 at 10:53:12PM -0400, Bruce Momjian wrote:
On Sun, Mar 22, 2015 at 04:41:19PM -0400, Noah Misch wrote:
On Wed, Mar 18, 2015 at 05:52:44PM -0400, Bruce Momjian wrote:
This junk digit zeroing matches the Oracle
On Sun, Mar 22, 2015 at 10:53:12PM -0400, Bruce Momjian wrote:
On Sun, Mar 22, 2015 at 04:41:19PM -0400, Noah Misch wrote:
On Wed, Mar 18, 2015 at 05:52:44PM -0400, Bruce Momjian wrote:
This junk digit zeroing matches the Oracle behavior:
SELECT
On Tue, Mar 24, 2015 at 09:47:56AM -0400, Noah Misch wrote:
On Sun, Mar 22, 2015 at 10:53:12PM -0400, Bruce Momjian wrote:
On Sun, Mar 22, 2015 at 04:41:19PM -0400, Noah Misch wrote:
On Wed, Mar 18, 2015 at 05:52:44PM -0400, Bruce Momjian wrote:
This junk digit zeroing matches the Oracle
On Tue, Mar 24, 2015 at 03:08:26PM -0400, Bruce Momjian wrote:
On Tue, Mar 24, 2015 at 10:05:12AM -0400, Bruce Momjian wrote:
On Tue, Mar 24, 2015 at 09:47:56AM -0400, Noah Misch wrote:
On Sun, Mar 22, 2015 at 10:53:12PM -0400, Bruce Momjian wrote:
On Sun, Mar 22, 2015 at 04:41:19PM
On Tue, Mar 24, 2015 at 09:26:10AM -0700, Jeff Anton wrote:
The issue of significant (decimal) digits to and from floating point
representation is a complex one.
What 'significant' means may depend upon the intent.
True. I meant simply that Oracle TO_CHAR emits no more than 17 nonzero
Jeff == Jeff Anton antonpg...@hesiod.org writes:
Jeff Postgresql seems to be using the first interpretation and
Jeff reporting fewer digits. I've noticed this with pg_dump. That a
Jeff dump and restore of floating point values does not produce the
Jeff same floating point values. To me,
The issue of significant (decimal) digits to and from floating point
representation is a complex one.
What 'significant' means may depend upon the intent.
There are (at least) two different tests which may need to be used.
* How many digits can be stored and then accurately returned?
or
* How
On Tue, Mar 24, 2015 at 10:05:12AM -0400, Bruce Momjian wrote:
On Tue, Mar 24, 2015 at 09:47:56AM -0400, Noah Misch wrote:
On Sun, Mar 22, 2015 at 10:53:12PM -0400, Bruce Momjian wrote:
On Sun, Mar 22, 2015 at 04:41:19PM -0400, Noah Misch wrote:
On Wed, Mar 18, 2015 at 05:52:44PM -0400,
-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Bruce Momjian
Sent: Tuesday, March 24, 2015 3:08 PM
To: Noah Misch
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Zero-padding and zero-masking fixes for
to_char(float)
On Tue, Mar 24, 2015 at 10:05
On Mon, Mar 23, 2015 at 12:36:25AM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sun, Mar 22, 2015 at 12:46:08PM -0400, Noah Misch wrote:
I recommend adding a configure test to use our snprintf.c replacements if
sprintf(%.*f, 65536, 999.0) gives unexpected output.
On Sun, Mar 22, 2015 at 01:42:56AM -0400, Tom Lane wrote:
David Rowley dgrowle...@gmail.com writes:
This seems to have broken jacana. Looks like MSVC by default has a 3 digit
exponent.
jacana was broken before this patch; but some other Windows critters
are now unhappy as well.
Going
On Sun, Mar 22, 2015 at 11:22:26AM -0400, Bruce Momjian wrote:
What has me more concerned is the Solaris 10 failure. This query:
SELECT to_char(float8 '999', 'D' || repeat('9',
1000));
expects this:
999.000...
but on Solaris 10
When you posted this, I made a note to review it.
On Wed, Mar 18, 2015 at 05:52:44PM -0400, Bruce Momjian wrote:
This junk digit zeroing matches the Oracle behavior:
SELECT to_char(1.123456789123456789123456789d,
'9.9') as x from dual;
--
On Sun, Mar 22, 2015 at 12:46:08PM -0400, Noah Misch wrote:
On Sun, Mar 22, 2015 at 11:22:26AM -0400, Bruce Momjian wrote:
What has me more concerned is the Solaris 10 failure. This query:
SELECT to_char(float8 '999', 'D' || repeat('9',
1000));
expects
On Sun, Mar 22, 2015 at 04:41:19PM -0400, Noah Misch wrote:
When you posted this, I made a note to review it.
On Wed, Mar 18, 2015 at 05:52:44PM -0400, Bruce Momjian wrote:
This junk digit zeroing matches the Oracle behavior:
SELECT to_char(1.123456789123456789123456789d,
On Sun, Mar 22, 2015 at 10:53:12PM -0400, Bruce Momjian wrote:
*** int4_to_char(PG_FUNCTION_ARGS)
*** 5214,5221
/* we can do it easily because float8 won't lose any
precision */
float8 val = (float8) value;
!
Bruce Momjian br...@momjian.us writes:
On Sun, Mar 22, 2015 at 12:46:08PM -0400, Noah Misch wrote:
I recommend adding a configure test to use our snprintf.c replacements if
sprintf(%.*f, 65536, 999.0) gives unexpected output.
Do we really want to go to our /port snprintf just to
On Wed, Mar 18, 2015 at 05:52:44PM -0400, Bruce Momjian wrote:
In September, while researching the to_char() buffer overflow bugs fixed
in 9.4.1 (commit 0150ab567bcf5e5913e2b62a1678f84cc272441f), I found an
inconsistency in how to_char() does zero-padding for float4/8 values.
Now that 9.4.1
On 22 March 2015 at 14:46, Bruce Momjian br...@momjian.us wrote:
On Wed, Mar 18, 2015 at 05:52:44PM -0400, Bruce Momjian wrote:
In September, while researching the to_char() buffer overflow bugs fixed
in 9.4.1 (commit 0150ab567bcf5e5913e2b62a1678f84cc272441f), I found an
inconsistency in
David Rowley dgrowle...@gmail.com writes:
This seems to have broken jacana. Looks like MSVC by default has a 3 digit
exponent.
jacana was broken before this patch; but some other Windows critters
are now unhappy as well.
Going by this:
In September, while researching the to_char() buffer overflow bugs fixed
in 9.4.1 (commit 0150ab567bcf5e5913e2b62a1678f84cc272441f), I found an
inconsistency in how to_char() does zero-padding for float4/8 values.
Now that 9.4.1 is released and I am home for a while, I am ready to
address this.
22 matches
Mail list logo
