Re: [GENERAL] numeric precision when raising one numeric to another.

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Cc: Alvaro Herrera <alvherre(at)surnet(dot)cl>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Subject: Re: [GENERAL] numeric precision when raising one numeric to another.
Date: 2005-06-04 14:09:58
Message-ID: 200506041409.j54E9xR17107@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-patches

Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > On Mon, May 30, 2005 at 11:29:48PM -0400, Bruce Momjian wrote:
> >
> > > test=> select 12345678901234567890 / 123;
> > > ?column?
> > > --------------------
> > > 100371373180768845
> > > (1 row)
> >
> > Well, that's a bug, right?
>
> I don't think so. The fuller answer is
> 100371373180768844.63414634146341463414, and that rounded to the nearest
> integer is 100371373180768845. I think people expect % do to that,
> except for integers. You could argue that numerics with zero scale are
> integers, but NUMERIC % NUMERIC doesn't behave like an integer operator
> --- it rounds to the proper precision.

Attached is a fix for the problem:

test=> select 12345678901234567890 % 123;
?column?
----------
78
(1 row)

I could have just forced X digits after the decimal point, but there was
really no _right_ number of digits, so it would have been a hack. The
proper solution is to change div_var to accept 'round' as true/false,
and that's what I did in the patch.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Attachment Content-Type Size
unknown_filename text/plain 8.1 KB

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Zlatko Calusic 2005-06-04 17:12:53 Re: PostgreSQL vs. InnoDB performance
Previous Message sql 2005-06-04 13:50:06 Re: postgresql books

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2005-06-04 15:49:11 Re: Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL
Previous Message Qingqing Zhou 2005-06-04 13:25:41 Re: Simplify Win32 Signaling code