Re: Fix number skipping in to_number
Oliver Ford <ojford@gmail.com>
From: Oliver Ford <ojford@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-11-13T21:07:34Z
Lists: pgsql-hackers
On Monday, 13 November 2017, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Oliver Ford <ojford@gmail.com <javascript:;>> writes:
> > On Sun, Nov 12, 2017 at 7:00 PM, Tom Lane <tgl@sss.pgh.pa.us
> <javascript:;>> 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
>
It's a guess as to the likely use case. I would imagine that people are
likely to use a currency symbol different from the locale, but unlikely to
use a different group separator. Others might have a different opinion
though.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Improve to_date/to_number/to_timestamp behavior with multibyte characters.
- 976a1a48fc35 11.0 landed
-
Prevent to_number() from losing data when template doesn't match exactly.
- e87d4965bd39 11.0 landed