On Thu, 1 Dec 2022 at 07:39, Sayyid Ali Sajjad Rizavi <sasriz...@gmail.com> wrote: > > Whenever rounding a number to a fixed number of decimal points in a > calculation, we need to cast the number into a numeric before using > round((col1/100.0)::numeric, 2). > > It would be convenient for everyone if round() also accepts float and double > precision. > > Is this something I could work with? And is that feasible?
I don't immediately see any issues with adding such a function. We do have some weirdness in some existing overloaded functions. pg_size_pretty() is an example. If you run: SELECT pg_size_pretty(1000); you get: ERROR: function pg_size_pretty(integer) is not unique That occurs because we don't know if we should promote the INT into a BIGINT or into a NUMERIC. We have a pg_size_pretty() function for each of those. I don't think the same polymorphic type resolution problem exists for REAL, FLOAT8 and NUMERIC. If a literal has a decimal point, it's a NUMERIC, so it'll just use the numeric version of round(). I'm unsure what the repercussions of the fact that REAL and FLOAT8 are not represented as decimals. So I'm not quite sure what real guarantees there are that the number is printed out with the number of decimal places that you've rounded the number to. Doing: create function round(n float8, d int) returns float8 as $$ begin return round(n::numeric, d)::float8; end; $$ language plpgsql; and running things like: select round(3.333333333333333::float8,10); I'm not seeing any issues. David
