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 afr
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
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:
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 di
essage-
> From: pgsql-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
> t
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:44P
> "Jeff" == Jeff Anton 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, that is inex
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 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
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 to_char(1.12345678912345
On Mon, Mar 23, 2015 at 12:36:25AM -0400, Tom Lane wrote:
> Bruce Momjian 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 Mon, Mar 23, 2015 at 12:36:25AM -0400, Tom Lane wrote:
> Bruce Momjian 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.
>
Bruce Momjian 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 handle 512+
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;
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 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));
> >
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 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 Sola
On Sun, Mar 22, 2015 at 01:42:56AM -0400, Tom Lane wrote:
> David Rowley 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:
David Rowley 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:
> https://msdn.microsoft.com/en-us/library/0fatw238(v=vs.80).aspx it seems
On 22 March 2015 at 14:46, Bruce Momjian 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 how to_char
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.
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.
F
23 matches
Mail list logo
