Lists: | pgsql-hackerspgsql-patches |
---|
From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | to_char/to_number loses sign |
Date: | 2004-10-23 13:40:35 |
Message-ID: | 200410231540.35363.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
This is from one of the examples in the documentation:
SELECT to_char(-485, '999S');
to_char
---------
485-
The reverse doesn't work as well:
SEKLECT to_number('485-', '999S');
to_number
-----------
485
Is this a bug or intentional?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
Subject: | Re: to_char/to_number loses sign |
Date: | 2004-10-23 21:25:52 |
Message-ID: | 27578.1098566752@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> SELECT to_number('485-', '999S');
> to_number
> -----------
> 485
> Is this a bug or intentional?
Tracing through this, it looks like the problem is that NUM_processor()
has no switch case for NUM_S (nor does the default case raise an error,
which seems a risky practice to me).
Karel, can you verify this and submit a fix?
regards, tom lane
From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, List pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: to_char/to_number loses sign |
Date: | 2004-10-25 13:30:22 |
Message-ID: | 1098711022.19187.26.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
On Sat, 2004-10-23 at 17:25 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > SELECT to_number('485-', '999S');
> > to_number
> > -----------
> > 485
>
> > Is this a bug or intentional?
>
> Tracing through this, it looks like the problem is that NUM_processor()
> has no switch case for NUM_S (nor does the default case raise an error,
> which seems a risky practice to me).
>
> Karel, can you verify this and submit a fix?
Yes, you're right. It strange, but NUM_S missing there. The conversion
from string to number is less stable part of formatting.c...
I have already 2000 lines of code of new generation of to_..()
functions. But all will available in 8.1.
The patch is in the attachment.
Karel
--
Karel Zak
http://home.zf.jcu.cz/~zakkr
Attachment | Content-Type | Size |
---|---|---|
pgsql-formatting-10252004.patch | text/x-patch | 775 bytes |
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, List pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: to_char/to_number loses sign |
Date: | 2004-10-26 17:27:24 |
Message-ID: | 11671.1098811644@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:
> Yes, you're right. It strange, but NUM_S missing there. The conversion
> from string to number is less stable part of formatting.c...
> The patch is in the attachment.
This patch causes the regression tests to fail. I think you need to
consider the to_char() side of it more carefully.
regards, tom lane
From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, List pgsql-patches <pgsql-patches(at)postgreSQL(dot)org> |
Subject: | sign parsing (was: Re: [HACKERS] to_char/to_number loses sign) |
Date: | 2004-10-27 11:59:38 |
Message-ID: | 1098878378.19187.76.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
On Tue, 2004-10-26 at 13:27 -0400, Tom Lane wrote:
> Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:
> > Yes, you're right. It strange, but NUM_S missing there. The conversion
> > from string to number is less stable part of formatting.c...
>
> > The patch is in the attachment.
>
> This patch causes the regression tests to fail. I think you need to
> consider the to_char() side of it more carefully.
Sorry of this in beta version...
The problem was bigger than I expected. I hope it's fixed in actual
patch. All regression tests pass.
The patch changes two lines in regression test too. It's because old
version of to_number() allows to use wrong number input and this input
was in regression test. The call to_char(-0.01, ' 9 9 . 9 9 S'); never
produced ' . 0 1 -' but always ' . 0 1-' only.
-SELECT '' AS to_number_13, to_number(' . 0 1 -', ' 9 9 . 9 9 S');
+SELECT '' AS to_number_13, to_number(' . 0 1-', ' 9 9 . 9 9 S');
^^^
'S' = locale sign and it must be always anchored to last or first
number.
Again sorry,
Karel
--
Karel Zak
http://home.zf.jcu.cz/~zakkr
Attachment | Content-Type | Size |
---|---|---|
pgsql-formatting-10272004.patch.gz | application/x-gzip | 2.4 KB |
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
Cc: | List pgsql-patches <pgsql-patches(at)postgreSQL(dot)org> |
Subject: | Re: sign parsing (was: Re: [HACKERS] to_char/to_number loses sign) |
Date: | 2004-10-28 18:55:45 |
Message-ID: | 5059.1098989745@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:
> The problem was bigger than I expected. I hope it's fixed in actual
> patch. All regression tests pass.
Applied, thanks.
regards, tom lane