From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "Greg Smith" <gsmith(at)gregsmith(dot)com> |
Cc: | rrahul <rahul(dot)rathi(at)cognizant(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: postgre vs MySQL |
Date: | 2008-03-11 23:32:31 |
Message-ID: | dcc563d10803111632w75b78f92mf3805ba0eb91a7a7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Mar 11, 2008 at 4:22 PM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
> On Tue, 11 Mar 2008, Scott Marlowe wrote:
>
> > That kind of change does NOT get into production versions of
> > postgresql. With a yearly release schedule, postgresql doesn't have
> > to put dodgy performance updates in a production release.
>
> This is worth expanding on: PostgreSQL doesn't put *any* feature changes
> in a production release. Once it's a stable release, only bug fixes are
> applied. Any other way is madness.
I'm really hoping Sun will put a stop to such behavior, but wonder if
they'll do anything at all.
Sadly, the worst problem with the behavior re mysql releases is that
it trains DBAs to NOT install updates. In fairness, I know quite a
few Oracle DBAs who won't install patches right away either.
Then they come to postgresql and run a release missing a year or more
of updates.
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Turner | 2008-03-12 00:11:32 | Re: postgre vs MySQL |
Previous Message | Scott Marlowe | 2008-03-11 23:28:40 | Re: Array load from remote site through Perl/DBI |