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

On Saturday 23 July 2005 16:15, Jim C. Nasby wrote:
> On Sat, Jul 23, 2005 at 02:27:51PM -0400, Robert Treat wrote:
> > On Saturday 23 July 2005 12:43, Jim C. Nasby wrote:
> > > I think we need to do 2 things to ensure PostgreSQL doesn't get
> > > relegated to niche status.
> >
> > as a side question, do you feel BSD is a niche operating system?
>
> All things considered, yes. This is especially true outside of ISP's.
> But, there's something even more important than userbase, and that's
> development effort. I think it's pretty easy to see that linux is
> clearly ahead of *BSD there.

Ah, but this is one of the advantages we have over my$ql that bsd did not have
over linux, which is that we are able to better harness the development
efforts of our community than my$ql is.  Between the GPL license, and more
importantly the tight copyright controls around the my$ql code base, it just
isn't feasible for companies to jump in and extend thier system. That
development has to be done in house, but with us it can be done from any
number of sources.  This isn't that bsd doesnt have these aspects, but linux
had them as well, so there was no advantage there. In the long run we have a
big advantage over my$ql in this area.

>
> > > First, we need to counter MySQL's FUD. MySQL
> > > has a laundry-list of 'companies that are using mysql', even though it
> > > doesn't mean anything more than they've got it sitting on a server
> > > somewhere. Of course there's also they're misrepresentive benchmarks.
> >
> > pgsql inc has something like this, a registered users site (or at least
> > they used to).  I have on my todo to convert that into something for the
> > main www site, but it's gonna be awhile before I get to it. Of course if
> > anyone is interested in picking it up, shoot me an email.
>
> Maybe put the code in pg-foundry so it's easy for people to help?
>

Heh, let's rehash this again eh? The code is on gborg, there is even a
question in the FAQ pointing people to the project and mailing lists for
people who are interested in contributing.

>
> > > 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.
> >
> > I always get concerned when things devolve into a pg vs my$ql scenario.
> > What I think we need to do is make it easier for people to convert from
> > $ql $erver and oracle to postgresql.  They have larger user bases and
> > have folks willing to pay for development/support.  If we can make it
> > simple enough that 50% of the people using my$ql all switch to postgres,
> > but my$ql goes after the corporations and gets 50% of them to switch to
> > my$ql, were not going to come out on top.
>
> I absolutely agree that we should be assisting in the migration from
> Oracle and MSSQL, but there's already a good amount of focus on that (as
> well there should be).
>
> 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.

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

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL