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

On Sat, Jul 23, 2005 at 04:46:52PM -0400, Robert Treat wrote:
> > But I think it's also folly not to promote MySQL->PostgreSQL migration.
> > The only advantage MySQL has over PostgreSQL is the size of the user
> > community. More users means more tools means more apps written for MySQL
> > means more users, etc. Many times people start off on MySQL then find
> > themselves wishing they hadn't once they get some exposure to
> > PostgreSQL. Yet they stay with MySQL because of how difficult it would
> > be to migrate. So they stay MySQL users, giving MySQL more momentum.
> >
>
> I'm not saying we don't want people to convert, but if the end goal is to
> increase the user base, why go after a small piece of the pie? I think that
> the $ql$erver/oracle user bases are signifigantly larger than my$qls that it
> offsets an ease of convincing that you might have when dealing with my$ql
> users.

Because that small piece of the pie is where the next generation of
decision makers is comming from, as well as a lot of coders. If all
people at a company are hearing about is MySQL, then odds are they might
not even look at PostgreSQL.

Also, realistically there's a lot of territory owned by the big 3 that
PostgreSQL isn't going to be able to move into anytime soon, for
different reasons. In the meantime when geeks in the back offices at
companies reach for an OSS database to use in some small project, which
would you rather it be, MySQL or PostgreSQL? Keep in mind that as OSS
databases get a foothold in companies through the back door, whichever
one is more popular at a company is going to be more likely to be
adopted as the corporate standard. This is one of the ways Linux worked
it's way into corporations, and it's why it's important for both the
PostgreSQL community and companies that offer PostgreSQL services that
these back-room projects use PostgreSQL and not MySQL.

> > Fortunately, since MySQL is a fairly simple database, it wouldn't be
> > too difficult to offer features that would greatly ease migration. Even
> > some simple things like providing an equivalent to enum would probably
> > go a long way.
>
> I can see why people like enum, but its just not a sound way to do things.
> It's kind of like how they do timestamps, sure its handy in some scenarios,
> but just dumb in others. I don't think your ever going to see these features
> put into mainline postgresql. Maybe you can get enterprisedb to code up a
> "uppsala" mode, but outside of that I think you'd just be better off making a
> website listing specific my$ql features, why people find fault in them, and
> then how to work around them in pg.

Oh, sure, there's plenty of 'features' in MySQL that aren't the best way
to do something, but unless it breaks ACID I see no reason not to at
least allow them in PostgreSQL to ease migration. Some of these things
might require back-end changes, but I suspect most of them could be done
through contrib or pg-foundry. Since enum would be a new type it
probably doesn't require backend changes.

And yes, I know I could well be the one to provide an enum type for
people to use, but if people think increased support for conversion from
MySQL is a Good Thing (tm) then we should figure out what things are
most painful for people converting an focus on them.

Out of curiosity, how do they do timestamps differently? Other than
supporting things like, Feb. 31st.
--
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?"