Re: [PATCH] Add roman support for to_number function - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Add roman support for to_number function
Date
Msg-id 3346875.1737474536@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Add roman support for to_number function  (Hunaid Sohail <hunaidpgml@gmail.com>)
List pgsql-hackers
Hunaid Sohail <hunaidpgml@gmail.com> writes:
> The leading spaces are consumed in the RN (from the main loop
> in Num_processor), and this behavior seems consistent with how
> simple numbers are handled. The Roman numeral parsing
> appears to start from where "RN" is in the format after
> leading spaces are consumed.

Yes, a space in the format string should consume a character
from the input (whether it's a space or not).

regression=# select to_number('x123', '999');
 to_number 
-----------
        12
(1 row)

regression=# select to_number('x123', ' 999');
 to_number 
-----------
       123
(1 row)

I used to think that a space in the format would consume any number of
spaces from the input, but that doesn't seem to be true --- I think
I was misled by that perhaps-bug in NUM_numpart_from_char.  For
example:

regression=# select to_number('   123', ' 999');
 to_number 
-----------
        12
(1 row)

One of the three input spaces is eaten by the format space, and
one is taken as the sign, and then the 9's match ' 12'.  (I don't
think we should be expecting a sign in RN though.)  However,
as we add more input spaces:

regression=# select to_number('    123', ' 999');
 to_number 
-----------
        12
(1 row)

regression=# select to_number('     123', ' 999');
 to_number 
-----------
         1
(1 row)

This is bizarrely inconsistent, and I think what's causing it
is the extra space-consumption in NUM_numpart_from_char.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Ivan Kush
Date:
Subject: Re: pg_stat_statements: improve loading and saving routines for the dump file
Next
From: Nathan Bossart
Date:
Subject: Re: Pre-allocating WAL files