Thread: Help convincing a vendor....
to include PostgreSQL in addition to MySQL in an enhancement package. 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). Anyone on this list have arguments I can use? I can't say the vendors name due to NDA, but if you've seen my postings, you can guess. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
On Tue, 15 Jul 2003, Larry Rosenman wrote: > to include PostgreSQL in addition to MySQL in an enhancement package. > > 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). > > Anyone on this list have arguments I can use? > > I can't say the vendors name due to NDA, but if you've seen my postings, > you can guess. 1: MySQL 4.1 GPLs the connect libs. I.e. either you buy a commercial license or you GPL your code. Hence, all installations this vendor wants to sell will need to include a commercially licensed MySQL. 2: supporting ANSI standard SQL is a good idea (TM) because it makes it that much easier to port to other databases. I.e. the initial cost of porting to Postgresql makes porting to the third, fourth, etc... databases that much easier. 3: Stability and load handling are better in Postgresql. But you already kinda mentioned that one.
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.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
--On Tuesday, July 15, 2003 15:49:47 -0400 Andrew Sullivan <andrew@libertyrms.info> 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. > > A Good one. I hadn't seen that till recently on one list here or another. Keep 'em coming folks. I'm forwarding to the beta coordinator. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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...
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)