On Thu, 1 Dec 2022 at 02:58, David Rowley <dgrowle...@gmail.com> wrote: > > On Thu, 1 Dec 2022 at 15:41, David G. Johnston > <david.g.johns...@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 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
