Thread: to_char/to_number loses sign
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/
Peter Eisentraut <peter_e@gmx.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
On Sat, 2004-10-23 at 17:25 -0400, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.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
Karel Zak <zakkr@zf.jcu.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