Re: Allow round() function to accept float and double precision
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>,
Sayyid Ali Sajjad Rizavi <sasrizavi@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2022-12-01T02:41:08Z
Lists: 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.
Commits
-
Doc: add example of round(v, s) with negative s.
- e10799aa252c 15.2 landed
- a475157e6bf0 13.10 landed
- a109a0bb50ad 16.0 landed
- 7ec2bfe9e031 14.7 landed