Re: [HACKERS] Fix number skipping in to_number

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Oliver Ford <ojford@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-11-13T16:26:27Z
Lists: pgsql-hackers
Oliver Ford <ojford@gmail.com> writes:
> On Sun, Nov 12, 2017 at 7:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * Don't we need to fix the NUM_L (currency symbol) case in the
>> same manner?  (The NUM_D and NUM_S cases are handled in
>> NUM_numpart_from_char and seem ok at a quick glance.)

> Yes you get the same skipping if you do:

> select to_number('12','L99');
>  to_number
> -----------
>          2

> However, this case is not as easy to fix as you can't do a simple
> string comparison like with the group separator. The currency symbol
> for the locale can be " " but if we do a comparison, it won't match if
> the symbol specified is "$" or "£" (so will end up missing characters
> at the end of the supplied string). Could we apply the attached patch
> and then put fixing it for currency on the TODO list?

I don't follow your concern?  If "$" is not the correct currency
symbol for the locale, we shouldn't accept it as a match to an L format.
Your patch is tightening what we will accept as a match to a G format,
so I don't see why you're concerned about backward compatibility in
one case but not the other.

			regards, tom lane


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Improve to_date/to_number/to_timestamp behavior with multibyte characters.

  2. Prevent to_number() from losing data when template doesn't match exactly.