From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oliver Ford <ojford(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Fix number skipping in to_number |
Date: | 2017-11-13 16:26:27 |
Message-ID: | 11110.1510590387@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Oliver Ford <ojford(at)gmail(dot)com> writes:
> On Sun, Nov 12, 2017 at 7:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Geoff Winkless | 2017-11-13 16:41:59 | Re: Migration to PGLister - After |
Previous Message | Oliver Ford | 2017-11-13 16:18:44 | Re: [HACKERS] Fix number skipping in to_number |