Re: Fix number skipping in to_number
Oliver Ford <ojford@gmail.com>
From: Oliver Ford <ojford@gmail.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-17T11:33:02Z
Lists: pgsql-hackers
Attachments
- 0001-apply-number-v3.patch (application/octet-stream) patch v3-0001
On Thu, Aug 17, 2017 at 11:55 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > Hmm. Just in case my macOS laptop (CC=Apple's clang, > LANG=en_NZ.UTF-8) was unduly affected by cosmic rays I tried on a > couple of nearby servers running FreeBSD 11.1 (CC=clang, LANG=<unset>) > and CentOS 7.3 (CC=gcc, LANG=en_US.utf-8) and got the same result: > int8 has lost some whitespace in to_char output. > > It looks a bit like it has lost a leading space for every ',' that was > present in the format string but which didn't finish up getting output > (because the number was too small). It looks a bit like that doesn't > happen for 'G', so let's compare the NUM_COMMA and NUM_G cases. Ahh.. > I'm not sure, but I think you might have a close-brace in the wrong > place here: > > @@ -4879,6 +4883,10 @@ NUM_processor(FormatNode *node, NUMDesc *Num, > char *inout, > continue; > } > } <--- this guy here might > need to move after "noadd = true"? > + if > (strncmp(Np->inout_p, Np->L_thousands_sep, separator_len) == 0) > + Np->inout_p += > separator_len - 1; > + else > + noadd = true; > break; > > case NUM_G: > > With that change the test passes for me. But why do we get different results? > > -- > Thomas Munro > http://www.enterprisedb.com Ok I've made that change in the attached v3. I'm not sure as I'm on en_US.UTF-8 locale too. Maybe something Windows specific?
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