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

On Wed, Nov 30, 2022 at 6:45 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David Rowley <dgrowleyml(at)gmail(dot)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.