On Mon, Nov 30, 2015 at 11:24 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Nov 30, 2015 at 11:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Michael Paquier <michael.paqu...@gmail.com> writes: >>> On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote: >>>> Instinctively, it seems to me that we had better return Nan for the >>>> new asind and acosd when being out of range for OSX, Linux will >>>> complain about an out-of-range error so the code is right in this >>>> case. >> >>> This is still mentioned upthread btw. And it does not seem to be a >>> good idea to change this platform dependent behavior by throwing an >>> error on the old functions, neither does it seem user-friendly to have >>> inconsistent results for the XXX function and its XXXd equivalent. >> >> FWIW, I think that probably the best course of action is to go ahead >> and install POSIX-compliant error checking in the existing functions >> too. POSIX:2008 is quite clear about this: >> >> : An application wishing to check for error situations should set errno to >> : zero and call feclearexcept(FE_ALL_EXCEPT) before calling these >> : functions. On return, if errno is non-zero or fetestexcept(FE_INVALID | >> : FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW) is non-zero, an error has >> : occurred. > > OK, I have to admit I didn't know this part. > >> Although I'm not too sure about Windows, the inconsistent results >> we're getting on OS X are certainly from failure to adhere to the spec. > > Windows complains about out-of-range errors contrary to OSX on for > example asin or acos. So for once Linux and Windows agree with each > other. > >> I concur with Peter's opinion that this is material for a separate >> patch, but it seems like it's one that had better go in first. > > (I think you mean Dean here and not Peter).
Dean, are you planning to continue working on this patch? If yes, are you fine to move it to next CF? It seems that the current consensus is to split this effort into two patches: 1) Harden error checks for existing functions, particularly the inconsistencies for asin and acos. 2) Have the new functions in degrees. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
