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