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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers