From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Sayyid Ali Sajjad Rizavi <sasrizavi(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Allow round() function to accept float and double precision |
Date: | 2022-12-01 14:39:53 |
Message-ID: | 1565775.1669905593@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> 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).
Right, but I think what the OP wants is to not have to think about
whether the input is of exact or inexact type. That's easily soluble
locally by making your own function:
create function round(float8, int) returns numeric
as $$select pg_catalog.round($1::pg_catalog.numeric, $2)$$
language sql strict immutable parallel safe;
but I'm not sure that the argument for it is strong enough to
justify putting it into Postgres.
> The fact that passing a negative scale to round() isn't documented
> does seem like an oversight though...
Agreed, will do something about that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | gkokolatos | 2022-12-01 14:58:35 | Re: Add LZ4 compression in pg_dump |
Previous Message | David G. Johnston | 2022-12-01 14:35:15 | Re: [DOCS] Stats views and functions not in order? |