On Thu, 1 Dec 2022 at 02:58, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Thu, 1 Dec 2022 at 15:41, David G. Johnston
> <david.g.johnston@gmail.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
yousay, it is actually more of a type conversion with an ability to specify precision, which is exactly what you get
todaywhen 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
