Re: Allow round() function to accept float and double precision

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Allow round() function to accept float and double precision
Дата
Msg-id CAKFQuwZ4Vy1Xty0G5Ok+ot=NDrU3C6hzF1JwUk-FEkwe3V9_RA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Allow round() function to accept float and double precision  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Allow round() function to accept float and double precision  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
On Wed, Nov 30, 2022 at 6:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Rowley <dgrowleyml@gmail.com> writes:
 
> I'm unsure what the repercussions of the fact that REAL and FLOAT8 are
> not represented as decimals.

The main thing is that I think the output will still have to be
NUMERIC, or you're going to get complaints about "inaccurate"
results.  Before we got around to inventing infinities for NUMERIC,
that choice would have been problematic, but now I think it's OK.


I don't get the point of adding a function here (or at least one called round) - the type itself is inexact so, as you say, it is actually more of a type conversion with an ability to specify precision, which is exactly what you get today when you write 1.48373::numeric(20,3) - though it is a bit annoying having to specify an arbitrary precision.

At present round does allow you to specify a negative position to round at positions to the left of the decimal point (this is undocumented though...) which the actual cast cannot do, but that seems like a marginal case.

Maybe call it: make_exact(numeric, integer) ?

I do get a feeling like I'm being too pedantic here though...

David J.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Fujii.Yuki@df.MitsubishiElectric.co.jp"
Дата:
Сообщение: RE: Partial aggregates pushdown
Следующее
От: David Rowley
Дата:
Сообщение: Re: Allow round() function to accept float and double precision