Обсуждение: Make Windows print float exponents like everybody else?

I can't believe I got no comments about this, so reposting it under
a more attention-getting title ...

In https://www.postgresql.org/message-id/29037.1539021687@sss.pgh.pa.us
I wrote:

> Also, we have quite a few variant expected-files that exist only to cater
> for Windows' habit of printing three exponent digits where everybody else
> prints just two.  It struck me that it would not be hard, or expensive,
> to undo that choice in snprintf.c (see attached untested patch).  So we
> could considerably reduce future maintenance pain for the affected tests
> by getting rid of those files.
>
> As against that, Windows users might possibly complain that float output
> looks different than they're used to.  I'm not sure how much sympathy
> I have for that position.  If we reimplement float output for more speed,
> as is under discussion in nearby threads, I doubt we'd trouble to preserve
> this Windows-ism in the rewrite.
>
> Comments?

If I don't get any pushback I'm going to go do that...

            regards, tom lane

Hi,

On 2018-10-09 18:00:54 -0400, Tom Lane wrote:
> I can't believe I got no comments about this, so reposting it under
> a more attention-getting title ...
> 
> In https://www.postgresql.org/message-id/29037.1539021687@sss.pgh.pa.us
> I wrote:
> 
> > Also, we have quite a few variant expected-files that exist only to cater
> > for Windows' habit of printing three exponent digits where everybody else
> > prints just two.  It struck me that it would not be hard, or expensive,
> > to undo that choice in snprintf.c (see attached untested patch).  So we
> > could considerably reduce future maintenance pain for the affected tests
> > by getting rid of those files.
> >
> > As against that, Windows users might possibly complain that float output
> > looks different than they're used to.  I'm not sure how much sympathy
> > I have for that position.  If we reimplement float output for more speed,
> > as is under discussion in nearby threads, I doubt we'd trouble to preserve
> > this Windows-ism in the rewrite.
> >
> > Comments?

No pushback here. Lower likelihood of turning the buildfarm red, lower
likelihood of being embarrased. Good. ;)

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2018-10-09 18:00:54 -0400, Tom Lane wrote:
>>> Also, we have quite a few variant expected-files that exist only to cater
>>> for Windows' habit of printing three exponent digits where everybody else
>>> prints just two.  It struck me that it would not be hard, or expensive,
>>> to undo that choice in snprintf.c (see attached untested patch).  So we
>>> could considerably reduce future maintenance pain for the affected tests
>>> by getting rid of those files.

> No pushback here. Lower likelihood of turning the buildfarm red, lower
> likelihood of being embarrased. Good. ;)

Some (but curiously, not all) of the Windows critters are unhappy with
the fact that I removed the extra expected files for the ECPG tests.
In retrospect, the reason is obvious: the ECPG test programs do not
include port.h nor link with src/common, so they're not using our
custom printf, just the platform native one.

I could just revert the ECPG aspects of that commit, but considering
that it seems like everything else works, it's annoying to still need
extra expected files for ECPG.

What I'm now thinking about is modifying the three affected test
programs so that they internally strip the extra zero using the
same logic as in snprintf.c.  It'd be slightly more work but
might be worth it in the long run.  On the other hand, we hardly
ever touch the ECPG tests anyway, so maybe it isn't?

            regards, tom lane