On Mon, Oct 2, 2017 at 4:23 AM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > For other potential reviewers: > > I found the origin of the function here. > > https://www.postgresql.org/message-id/4a90bd76.7070...@netspace.net.au > https://www.postgresql.org/message-id/AANLkTim4cHELcGPf5w7Zd43_dQi_2RJ_b5_F_idSSbZI%40mail.gmail.com > > And the reason for pg_hypot is seen here. > > https://www.postgresql.org/message-id/407d949e0908222139t35ad3ad2q3e6b15646a27d...@mail.gmail.com > > I think the replacement is now acceptable according to the discussion. > ======
I think if we're going to do this it should be separated out as its own patch. Also, I think someone should explain what the reasoning behind the change is. Do we, for example, foresee that the built-in code might be faster or less likely to overflow? Because we're clearly taking a risk -- most trivially, that the BF will break, or more seriously, that some machines will have versions of this function that don't actually behave quite the same. That brings up a related point. How good is our test case coverage for hypot(), especially in strange corner cases, like this one mentioned in pg_hypot()'s comment: * This implementation conforms to IEEE Std 1003.1 and GLIBC, in that the * case of hypot(inf,nan) results in INF, and not NAN. I'm potentially willing to commit a patch that just makes the pg_hypot() -> hypot() change and does nothing else, if there are not objections to that change, but I want to be sure that we'll know right away if that turns out to break. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
