Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Enticing interns to PostgreSQL

From: Chris Travers <chris(at)travelamericas(dot)com>
To: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>,PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: [HACKERS] Enticing interns to PostgreSQL
Date: 2005-07-26 19:26:57
Message-ID: 42E68E81.6060701@travelamericas.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
Jim C. Nasby wrote:

>But the problem is that grassroots OSS movements change the market once
>they get large enough. 10, or even 5 years ago it was impossible to get
>linux into big business, for many of the reasons you mentioned. But
>that's changed, even though *BSD was technically superior. It changed
>because there was a virtual army of linux users who wanted very badly to
>be able to use linux at work. MySQL has more 'foot-soldiers' than
>PostgreSQL does, even if a lot of them are alienated.
>  
>
I don't want to get into a BSD v. Linux flamewar.  But I think that the 
most important thing that Linux did better than BSD was 
community-building.  Apache did an excellent job of community-building 
as well.

MySQL is currently sort of a de-facto standard.  However, I think we 
have a more involved community here with PostgreSQL.  We may have fewer 
footsoldiers, but our footsoldiers are better, more technically able, 
and form a larger core community than you have with MySQL.

As evidence, MySQL used to argue that PostgreSQL's rate of development 
was too fast, and that their slower rate was better because it meant 
things got done right.  Whatever.....

Finally, I would say that I have avoided MySQL since PostgreSQL 7.0 came 
out.  Like many people, I found MySQL easier to use before that point.  
But with advances in usability, PostgreSQL has become an extremely easy 
to use and powerful product.  I am able to get so much more done faster 
with PostgreSQL, and my queries run faster.  For example:

 SELECT ar1.invnumber AS invoice1, ar2.invnumber AS invoice2, 
ar1.amount, ar1.paid, ar1.duedate
   FROM ar ar1, ar ar2
  WHERE ar1.invnumber::numeric > (ar2.invnumber::numeric - 3::numeric) 
AND ar1.invnumber::numeric < (ar2.invnumber::numeric + 3::numeric) AND 
ar1.amount = ar2.amount
AND ar1.invnumber <> ar2.invnumber AND ar1.till::text = ar2.till::text 
AND ar1.duedate = ar2.duedate AND ar1.employee_id = ar2.employee_id AND 
NOT (ar1.id IN ( SELECT i1.trans_id
           FROM invoice i1
          WHERE i1.trans_id = ar1.id AND NOT (i1.parts_id IN ( SELECT 
i2.parts_id
                   FROM invoice i2
                  WHERE i2.trans_id = ar2.id AND i2.parts_id = 
i1.parts_id AND i1.qty = i2.qty)))) AND NOT (ar1.id IN ( SELECT ac1.trans_id
           FROM acc_trans ac1
          WHERE ac1.source IS NOT NULL AND ac1.trans_id = ar1.id AND NOT 
(ac1.amount IN ( SELECT ac2.amount
                   FROM acc_trans ac2
                  WHERE ar2.id = ac2.trans_id AND ac2.source = 
ac1.source AND ac2.source IS NOT NULL AND ac1.amount = ac2.amount)))) 
AND ar1.amount <> 0::double precision
  ORDER BY ar1.invnumber::numeric;

ran in a reasonable amount of time.  Running the same query in MySQL 
would have been much slower.

>Second (and probably more important), we need to make it easier for
>people to migrate to PostgreSQL from MySQL. There's a sizeable number of
>people who would like to migrate things off of MySQL if it wasn't so
>difficult, and hard to do incrementally. Adding support for some MySQL
>features (such as enum and tinyint), making it easy for PostgreSQL
>databases to talk to MySQL databases (perhaps via dblink), and providing
>methods to connect to PostgreSQL without having to tear out big chunks
>of un-abstracted code are some things that would help here.
>  
>
How hard would it be to automatically create enum_ tables in the back 
ground to emulate MySQL's enum type?  Sort of like we do with SERIAL 
datatypes...  Part of the problem is that MySQL's enum type is so 
braindead from a database design perspective that most of us would not 
be interested in using it.  Emulating an int foreign key for another 
created table might make it ok, though.

Also, why not simply allow tinyint to be the same as int(2)?

Personally, I agree that we should pursue MySQL compatibility along with 
compatibility for the large "real" RDBMS.  Simply because it means a 
larger, more diverse community.

Best Wishes,
Chris Travers
Metatron Technology Consulting

In response to

Responses

pgsql-hackers by date

Next:From: David WheelerDate: 2005-07-26 19:44:21
Subject: Re: Segfault Exiting psql
Previous:From: Tom LaneDate: 2005-07-26 19:17:57
Subject: Re: More buildfarm stuff

pgsql-advocacy by date

Next:From: Jim C. NasbyDate: 2005-07-26 19:50:40
Subject: Re: [HACKERS] Enticing interns to PostgreSQL
Previous:From: Brian KilpatrickDate: 2005-07-26 19:03:49
Subject: OSCON Field Trip to NWS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group