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

On Thu, 1 Dec 2022 at 02:58, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Thu, 1 Dec 2022 at 15:41, David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > 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.
>
> An additional problem with that which you might have missed is that
> you'd need to know what to specify in the precision part of the
> typemod. You might start getting errors one day if you don't select a
> value large enough. That problem does not exist with round(). Having
> to specify 131072 each time does not sound like a great solution, it's
> not exactly a very memorable number.
>

I don't really see the point of such a function either.

Casting to numeric(1000, n) will work fine in all cases AFAICS (1000
being the maximum allowed precision in a numeric typemod, and somewhat
more memorable).

Note that double precision numbers range in magnitude from something
like 2.2e-308 to 1.8e308, so you won't ever get an error (except, I
suppose, if you also chose "n" larger than 692 or so, but that would
be silly, given the input).

> > 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.

Note that, as of PG15, "n" can be negative in such typemods, if you
want to round before the decimal point.

The fact that passing a negative scale to round() isn't documented
does seem like an oversight though...

Regards,
Dean