Re: NaNs in numeric_power (was Re: Postgres 11 release notes)
От | Dean Rasheed |
---|---|
Тема | Re: NaNs in numeric_power (was Re: Postgres 11 release notes) |
Дата | |
Msg-id | CAEZATCW=3GDB3S92tXsCUxuE9jdEt7HWbHMWyX3Qc9FXP2u3cg@mail.gmail.com обсуждение исходный текст |
Ответ на | NaNs in numeric_power (was Re: Postgres 11 release notes) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: NaNs in numeric_power (was Re: Postgres 11 release notes)
|
Список | pgsql-hackers |
On 15 May 2018 at 22:55, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. > > Here's a proposed patch for that. > In the case 1 ^ NaN = 1, what should the result scale be? For other inputs, the result scale is at least as large as the scale of the first input, so I would suggest that the same ought to be the case here. Otherwise, this looks fine, and I agree that it makes thinks neater / more consistent. Regards, Dean
В списке pgsql-hackers по дате отправления: