> 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.
I included removal of pg_hypot() on my patch simply because the
comment on the function header is suggesting it. I though if we are
going to clean this module up, we better deal it first. I understand
the risk. The patches include more changes. It may be a good idea to
have those together.
> 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 don't see any tests of geometric types with INF or NaN. Currently,
there isn't consistent behaviour for them. I don't think we can
easily add portable ones on the current state, but we should be able
to do so with my patches. I will look into it.
> 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.
I can split this one into another patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers