Re: [HACKERS] Enticing interns to PostgreSQL

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