RE: NaNs in numeric_power (was Re: Postgres 11 release notes) - Mailing list pgsql-hackers

From Huong Dangminh
Subject RE: NaNs in numeric_power (was Re: Postgres 11 release notes)
Date
Msg-id 75DB81BEEA95B445AE6D576A0A5C9E936A76D959@BPXM05GP.gisp.nec.co.jp
Whole thread Raw
In response to NaNs in numeric_power (was Re: Postgres 11 release notes)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: NaNs in numeric_power (was Re: Postgres 11 release notes)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi, 

> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> David Rowley <david.rowley@2ndquadrant.com> writes:
> > On 16 May 2018 at 02:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> I'm not particularly fussed about getting credit for that.  However,
> >> looking again at how that patch series turned out --- ie, that we
> >> ensured POSIX behavior for NaNs only in HEAD --- I wonder whether we
> >> shouldn't do what was mentioned in the commit log for 6bdf1303, and
> >> teach numeric_pow() about these same special cases.
> >> It seems like it would be more consistent to change both functions
> >> for v11, rather than letting that other shoe drop in some future
> >> major release.
> 
> > I'm inclined to agree. It's hard to imagine these two functions
> > behaving differently in regards to NaN input is useful to anyone.
> 

Thank you. The patch looks fine to me.
Also, I have done the "make check" in Windows and Linux environment with no problem.


Thanks and best regards,
---
Dang Minh Huong
NEC Solution Innovators, Ltd.
http://www.nec-solutioninnovators.co.jp/en/

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: overhead of expression evaluation
Next
From: Pavel Stehule
Date:
Subject: Re: overhead of expression evaluation