Re: [PATCH] Add roman support for to_number function
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Hunaid Sohail <hunaidpgml@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org,
Maciek Sakrejda <m.sakrejda@gmail.com>,
Tomas Vondra <tomas@vondra.me>
Date: 2025-01-21T15:48:56Z
Lists: 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
Commits
-
Support RN (roman-numeral format) in to_number().
- 172e6b3adb2e 18.0 landed