public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tim Conrad <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: [email protected]
Cc: PostgreSQL-development <[email protected]>
Cc: PostgreSQL advocacy <[email protected]>
Subject: Re: [HACKERS] What can we learn from MySQL?
Date: Tue, 27 Apr 2004 11:27:54 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>

I've been sort-of reading this thread off and on, so this may
contain duplicate suggestions. 

I was researching an article I wrote about a comparison between
Postgres and MySQL recently (If you want, you can read the article
at http://www.devx.com/dbzone/Article/20743/). I noticed some clear
differences between the mysql.com website and the Postgres website.

1) Since MySQL AB supports and trains for MySQL, there's loads of
   training information available on their website. On the other
   hand, I had a hard time finding training information for Postgres
   in general. Same goes for support. It's easier to find, but it's
   still somewhat convoluted, IMO.

2) There doesn't seem to be a clear roadmap on Postgres features.
   When certian things are expected. There's the TODO list that
   Bruce maintains, but it only outlines 'near' fixes. MySQL has a
   nice listing of what to expect in certian future versions. I know
   it's not a perfect list, but it'd be nice to know when full blown
   replication will be included in PostgreSQL as an example.
   On those same lines, there doesn't seem to be anything about the
   improvements in the minor versions. It seems that in every
   release (i.e. 7.2,7.3,7.4) there are pretty significant changes,
   but finding a place that outlines these changes is somewhat
   difficult. 
   While being somewhat nit-picky on this, it'd also be helpful if
   someone wasn't completely database literate could understand some
   of the changes. Who needs transactions, anyways? :)

 3) There's the issues of 'advanced database features' in general.
    Many MySQL applications perform much of their logic in the
    application level, instead of the database level. They do this
    because there aren't things like triggers or stored procedures
    in MySQL. As the saying goes, 'if mohammad won't go to the
    mountain, bring the mountian to mohammad'. Why not do some
    simple explainations as to why these things are good, and what
    they do, and how to use them in real context?

 4) As other peole have noted, there's no windows build readily
    available for Postgres. There may be, but it's difficult to
    find. If someone's used to running, say, Oracle, and all they
    have is a windows machine to test something out on, MySQL has
    compiled binaries ready to go.

 5) I believe that this was noted as well somewhere along the line -
    the other tools, like pgadmin III aren't readily available
    either. They're excellent tools, and they should be quick to
    find on the postgres website.

 6) Bug tracking. I haven't really looked into how MySQL handles
    this, but when learning about Postgres, I discovered that the
    whole development model seemed kind of 'closed', and people on
    the mailing lists would find bugs repeatedly. Something like
    Bugzilla would be very helpful in this respect. I've been kind
    of out of the loop for the past 6 months in this area, so it may
    have changed since then.

 7) The two Postgres books are available online for anyone to read
    and download. They're there, but, to me, you have to notice them
    on the sidebar to go to them. They're extremely helpful, and
    they should be pointed out more.


Most of these suggestions aren't really anything to do with the
database itself. It's simply a re-organization of some of the
information that's already available. As others have mentioned,
'it's about the PR'. 

Just my $.02 worth.

Tim

view thread (145+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [HACKERS] What can we learn from MySQL?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox