Re: [HACKERS] Enticing interns to PostgreSQL - Mailing list pgsql-advocacy

On Tue, Jul 26, 2005 at 12:26:57PM -0700, Chris Travers wrote:
> 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.
Agreed. And this is why I think it's important to make it easy to bring
current MySQL users into the fold.

> 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.....

They also used to argue that table locking was better than row
locking...

So, how can we increase awareness amongst people who have yet to choose
an OSS database? Awareness that PostgreSQL exists, and awareness that
it's almost always a superior choice than MySQL.

> >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.

This is something that's been discussed on IRC, and got a favorable
response. In terms of compatability, I'd be happy with something that
just emulated MySQL. I think it would actually be good to allow for
both, since there are some limited cases where it doesn't make sense to
use an integer pointer to an external table.

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

Again, for simple compatability that would be fine. If alignment/padding
issues could be dealt with, it would also be handy to have a true
tinyint.

> 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.

Would you be interested in supporting a pg-foundry project that worked
on increasing mysql compatabality?
--
Jim C. Nasby, Database Consultant               decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"