Re: Help convincing a vendor....

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Andrew Sullivan <andrew(at)libertyrms(dot)info>
Cc: <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: Help convincing a vendor....
Date: 2003-07-15 20:33:46
Message-ID: Pine.LNX.4.33.0307151425490.28219-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy

On Tue, 15 Jul 2003, scott.marlowe wrote:

> On Tue, 15 Jul 2003, Andrew Sullivan wrote:
>
> > On Tue, Jul 15, 2003 at 11:28:32AM -0500, Larry Rosenman wrote:
> >
> > > I'm involved in a beta for some extensions for said vendor, and am looking
> > > for COGENT
> > > arguments for them to include BOTH MySQL (they already include MySQL in the
> > > package, and
> > > for the "other OS" may "have" to do PG for stability reasons).
> >
> > Well, what about, "We have to use PostgreSQL, because our accounting
> > department requires stability in numeric data. In MySQL, numeric()
> > gets stored internally as a float, and that leads to potential
> > problems in accounting applications."
> >
> > I didn't know about the numeric/float issue in MySQL, but I know for
> > sure that it would automatically disqualify it for anything we'd use
> > it for.
>
> See my recent correction about this. however, it wouldn't surprise me to
> find out that while they get stored as strings, they quite likely get
> operated on as floats...

OK, I did some testing. This script produces different output on mysql
than on postgresql (testing the mysql 3.23.xx version that comes with
RH7.2, and postgresql 7.3.3 installed from .tar.gz):

create table test (i1 numeric (10,2), i2 numeric(10,2));
insert into test values (123.123,123.123);
insert into test values (123.13,123.12);
select i1*i2 from test;

Postgresql produces this:

?column?
------------
15158.5344
15159.7656

While MySQL produces this:

+----------+
| i1*i2 |
+----------+
| 15158.53 |
| 15159.77 |
+----------+

Note that the mysql result is constrained by the numeric, and it's rounded
off.

Changing the select in postgresql to:

select (i1*i2)::numeric(10,2) from test;

gets the output in numeric format.

This loss of scale is against SQL spec, which states (SQL92 draft):

(QUOTE)

1) If the data type of both operands of a dyadic arithmetic operator is
exact numeric, then the data type of the result is exact numeric, with
precision and scale determined as follows:

a) Let S1 and S2 be the scale of the first and second operands
respectively.

b) The precision of the result of addition and subtraction is
implementation-defined, and the scale is the maximum of S1
and S2.

c) The precision of the result of multiplication is implementation
defined, and the scale is S1 + S2.

(/QUOTE)

Note that the result should therefore have a precion of (x,4)

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Robert Treat 2003-07-15 22:26:03 Re: 7.4 Press Release
Previous Message scott.marlowe 2003-07-15 20:14:25 Re: Help convincing a vendor....