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() side of it more carefully.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

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()
 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
--- pgsql/src/backend/utils/adt/formatting.c.num_s	2004-10-25 13:51:58.009789928 +0200
+++ pgsql/src/backend/utils/adt/formatting.c	2004-10-25 15:23:09.315025104 +0200
@@ -3625,7 +3625,7 @@
 {
 
 #ifdef DEBUG_TO_FROM_CHAR
-	elog(DEBUG_elog_output,  --- scan start --- );
+	elog(DEBUG_elog_output,  --- scan start --- %s, Np-number);
 #endif
 
 	if (*Np-inout_p == ' ')
@@ -3642,7 +3642,7 @@
 	/*
 	 * read sign
 	 */
-	if (*Np-number == ' '  (id == NUM_0 || id == NUM_9 || NUM_S))
+	if (*Np-number == ' '  (id == NUM_0 || id == NUM_9 || id == NUM_S))
 	{
 
 #ifdef DEBUG_TO_FROM_CHAR
@@ -4138,6 +4138,7 @@
 case NUM_0:
 case NUM_DEC:
 case NUM_D:
+case NUM_S:
 	if (Np-type == TO_CHAR)
 	{
 		NUM_numpart_to_char(Np, n-key-id);

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[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.org/~petere/


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

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,
which seems a risky practice to me).

Karel, can you verify this and submit a fix?

regards, tom lane

---(end of broadcast)---
TIP 8: explain analyze is your friend