Re: Why is MySQL more chosen over PostgreSQL? - Mailing list pgsql-hackers

On Tue, 2002-07-30 at 14:54, Hannu Krosing wrote:
> On Tue, 2002-07-30 at 16:00, Curt Sampson wrote:
> > On 30 Jul 2002, Hannu Krosing wrote:
> >
> > > On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote:
> > >
> > > > Bruce Momjian:
> > > > > It causes too much complexity in other parts of the system.
> > > >
> > > > That's one reason.
> > >
> > > Seems like somewhat valid reason. But still not enough to do a lot of
> > > work _and_ annoy a lot of existing users :)
> >
> > It's almost unquestionably more work to maintain than to drop. Dropping
> > support for it is a one-time operation. Maintaining it is an ongoing
> > expense.
>
> I would not rush to drop advanced features, as they may be hard to put
> back later. If they stay in, even in broken form, then there wont be
> nearly as much patches which make fixing them harder.

I seem to find this argument a lot on the list here.  For some reason,
many of the developers are under the impression that even if code is
never touched, it has a very high level of effort to keep it in the code
base.  That is, of course, completely untrue.  Now then, I'm not saying
that something as central as the topic at hand has a zero maintenance
cost associated with it, especially if it's constantly being run into by
the developers, but I do see it used WAY to often here for it to be
applicable in every case.

From what I can tell, in many cases, when one developer on the list
doesn't want to maintain or sees little value in a feature, it suddenly
seems to have a high price associated with it.  We need to be sure we're
making the distinction between, "I don't care to maintain this", and,
"maintaining this code is prohibitively high given it's feature
return...because...".   In other words, I find this argument used often
here will little to nothing used in context which would quantify it.
Worse yet, it generally goes unchallenged and unquestioned.

>
> I'm afraid that we have already dropped too much.
>
> For example we dropped time travel, but recent versions of Oracle now
> have some form of it, usable mostly for recovering accidentally deleted
> (and committed rows), although it is much harder to implement it using
> logs than using MVCC.

I must admit, I never understood this myself but I'm sure I'm ignorant
of the details.

> > That's a straw man argument.
>
> Actually it was meant to be 'one straw man against another straw man
> argument' ;)

Was clear to me!  I thought you made the point rather well.

>
> > What we (or I, anyway) are arguing is that
> > the relational model does everything that table inheritance does, and at
> > least as easily.
>
> The problem is that 'the relational model' does nothing by itself. It is
> always the developers/DBAs who have to do things.
>
> And at least for some brain shapes it is much more convenient to inherit
> tables than to (re)factor stuff into several tables to simulate
> inheritance using the relational model.

Agreed.  It's important to remember, there are some cases where the
conceptual implications can allow for more freedom in implementation.
This is the point that was being made with the "pure C" comment.  Sure,
I can do pretty much anything in asm, but that approach doesn't suddenly
invalidate every other way/language/concept/idiom to trying to
accomplish as given task.

Simply put, much of the power you get from any tool is often the
flexibility of a given tool to address a problem domain in many
different ways rather than just one.  Just because it doesn't fit your
paradigm doesn't mean it doesn't fit nicely into someone else's.

>
> I still think that inheritance should be enchanced and made compatible
> with standards not removed.

I completely agree with that!

>
> > Extending the model adds complexity without adding the
> > ability to do things you couldn't easily do before. (This, IMHO, makes
> > table inheritance quite inelegant.)
>
> Then explain why SQL99 has included inheritance ?
>

Yes please.  I'm very interested in hearing a rebuttal to this one.

Greg