On Thu, Aug 17, 2017 at 11:55 AM, Thomas Munro <thomas.mu...@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?
0001-apply-number-v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers