From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | Christopher Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pgsql vs mysql |
Date: | 2006-07-05 15:01:54 |
Message-ID: | 1152111714.13851.7.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, 2006-07-01 at 22:27, Christopher Browne wrote:
> In an attempt to throw the authorities off his trail, mmoncure(at)gmail(dot)com ("Merlin Moncure") transmitted:
> > hm. that's all very true (and important), but I try and keep focus
> > on the things besides basic correctness that drive the development
> > cultural divide that seperates the two communities. pg, besides
> > being a very project and surrounded by wonderful people, 'feels'
> > right when solving problems. why does it feel right? what kinds of
> > things in the database influence the development culture? pg
> > satisfies me on a much deeper level that transcends feature 'x' or
> > 'y' but stems from something much more vital and vibrant. it seems
> > like the biggest brains who really 'get it' are here, and that's why
> > I'm here.
>
> One cultural divide is that MySQL development takes place inside one
> private company, whereas PostgreSQL is developed by what truly is a
> global community. That difference has a lot of side-effects.
>
> One thing that doesn't quite stem directly from that is that there are
> definitely some deep thinkers in the PostgreSQL community. And they
> consistently think beyond the scope of any given immediate problem.
> They don't just try to patch over some immediate issue; they try to
> see if there's a further issue.
>
> For instance, we recently (in the last year) had some challenges
> compiling PostgreSQL on AIX, and reported as much. An "immediate"
> resolution might have been to tweak the config script a little. What
> we got instead was something of an audit of "weird libs still in use."
> A number of build changes were made to assortedly remove now-obsolete
> libs, and to have specific programs compile in only those libraries
> that they actually need. We'll see, when 8.2 is getting deployed, if
> this fully addresses our AIX issues; I expect it's close.
>
> What was interesting was that not only was the fix completely
> different from what was expected, but it became a more ambitious
> change that cleans up things on a lot of platforms.
>
> That seems not uncommon; someone comes, thinking they have The Answer
> to something. Further examination shows that it wasn't the right
> question, but someone figures out what that question should have been
> :-).
Now, contrast and compare that to these two mysql bugs in their RPM
packages:
http://bugs.mysql.com/bug.php?id=15223
http://bugs.mysql.com/bug.php?id=15255
Basically, a problem on bsd with libz resulted in mysql taking the road
of "let's just include out own libz".
Of course, the implementation broke building php from source, which is
pretty common when you need odd things like oracle or cracklib or ldap
or whatever. This problem showed up at then end of November 2005, and
has pretty much only had a bandaid placed over it.
The response I got from MySQL, since this problem affected us (we hit
MySQL, PostgreSQL and Oracle from our PHP enabled app server) was that
we should pay for commercial support. when I asked how that would help,
I was told that commercial support runs on older, more stable versions
of MySQL. That's not the kind of thing that makes me want to buy
commercial support. I can download and run older versions of MySQL all
by myself.
From | Date | Subject | |
---|---|---|---|
Next Message | John Purser | 2006-07-05 15:26:11 | Re: Inheritance and unique constraints |
Previous Message | Szymic1 | 2006-07-05 14:48:21 | Re: How to hide NOTICE messages in psql.exe ? |