On Thu, Dec 1, 2022 at 2:21 PM David Rowley wrote:
> On Fri, 2 Dec 2022 at 09:02, Tom Lane wrote:
> >
> > David Rowley writes:
> > > I don't really agree that it will work fine in all cases though. If
> > > the numeric has more than 1000 digits left of the decimal point then
> > > the method wo
On Fri, 2 Dec 2022 at 09:02, Tom Lane wrote:
>
> David Rowley writes:
> > I don't really agree that it will work fine in all cases though. If
> > the numeric has more than 1000 digits left of the decimal point then
> > the method won't work at all.
>
> But what we're talking about is starting fro
David Rowley writes:
> I don't really agree that it will work fine in all cases though. If
> the numeric has more than 1000 digits left of the decimal point then
> the method won't work at all.
But what we're talking about is starting from a float4 or float8
input, so it can't be more than ~308 d
On Thu, 1 Dec 2022 at 21:55, Dean Rasheed wrote:
> 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).
I wasn't aware of the typemod limit.
I don't really agree that it will work fine in
On Thu, Dec 1, 2022 at 7:39 AM Tom Lane wrote:
> Dean Rasheed writes:
>
> > The fact that passing a negative scale to round() isn't documented
> > does seem like an oversight though...
>
> Agreed, will do something about that.
>
>
Thanks. I'm a bit surprised you left "Rounds v to s decimal place
Dean Rasheed 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
On Thu, 1 Dec 2022 at 02:58, David Rowley wrote:
>
> On Thu, 1 Dec 2022 at 15:41, David G. Johnston
> wrote:
> > 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 a
On Thu, 1 Dec 2022 at 15:41, David G. Johnston
wrote:
> 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
On Wed, Nov 30, 2022 at 6:45 PM Tom Lane wrote:
> David Rowley 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 ab
David Rowley writes:
> 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
Yeah, you have to be careful about that when proposing to overloa
On Thu, 1 Dec 2022 at 07:39, Sayyid Ali Sajjad Rizavi
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 ac
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
12 matches
Mail list logo
