Re: [HACKERS] to_char/to_number loses sign

2004-10-26 Thread Tom Lane
Karel Zak <[EMAIL PROTECTED]> 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

Re: [HACKERS] to_char/to_number loses sign

2004-10-25 Thread Karel Zak
On Sat, 2004-10-23 at 17:25 -0400, Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> 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() > h

Re: [HACKERS] to_char/to_number loses sign

2004-10-23 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> 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,

[HACKERS] to_char/to_number loses sign

2004-10-23 Thread Peter Eisentraut
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.or