Re: What so special about PostgreSQL and other RDBMS?

"Volker Hetzer" <volker.hetzer_at_ieee.org> wrote in message news:<c7t0v0$sbv$1_at_nntp.fujitsu-siemens.com>...
> > And what was your reply?

> I asked first.

Is this grade school?

> > Realy, care to quote the part of the Contract that Gaurantees you any
> > rights?

> http://oracle.com/support/index.html?policies.html

I asked you to QUOTE the part of the Contract that Guarantees you any rights, not post a link to a description of support options and what they cost.

And even so, if you bother to read that page you would have noticed that it is mostly about protecting Oracle's rights from you, not granting you any.

For example:

 "Oracle may provide additional releases or versions of its programs in the form of an Update as part of our technical support services. It may become necessary as a part of Oracle's product lifecycle to desupport the programs and, therefore, Oracle reserves the right to desupport its programs."

What do think "Desupport its progams" means?

> > By "tested the contarct" what you mean is you agreed to pay them
> > completely on their terms and where satisified with the results they
> > chose to give you.

> So, in what way is it different from let's say, buying a cucumber?

If my application required a cucumber, I wouldn't sign a deal with a cucumber vendor that insisted I could only buy cucumbers from them, for ever, even if their cucumbers no longer work for me, while they could stop providing cucumbers any time they feel like it and still forbid me to use my own, proprietary cucumber dependant, application. I would, at least, make my application work with any cucumber.

This converation has gotten ridiculous, can it be that you really don't know the difference between a cucumber and an application dependency?

> > Have you tested alternatives?

> The other example was buyig gcc support from cygnus.
> One bug, never got resolved in one year, consequently
> we cancelled support.

Yet in this case, you could have purchaced gcc support from another company, however, without source, you would not have this option.

> > Are so so stupid that you actually expect a serious answer that was
> > obviously a
> > hostile attempt to insult by way of a rhetorical question?

> Ok, so for you explicitly: That was not a rhetorical question. Your response
> indicated youy didn't read my posting, or at least not the relevant part, so > I wanted to check whether it was worth posting any more.

What nonsence, please demonstrate this by comparison, I have clearly responded to all your arguments, regardless of how little sense they made.

You attempt empty rhetoric exactly because you have no real argument.

Worth posting what? Your great advice that developers should *NOT* abstract their code?

> I start to repeat myself here.

Too bad you have no actual argument to repeat, you are merely repeating your empty rhetoric and unsubstantiated bunk.

> The right to the source code does not mean
> anything useful, see the part you quoted below.

Yes it does, it's too bad you don't understand it.

If I have the source code, I know I can relly on a product for ever, and never talk to the original developer again if I so chose. Withouth source, the developer holds all the cards.

Let's take a simple case, say you hired a consultant to write you a simple
application, say a specialized contact manager.

When the project was over, would you let the consultant leave your office, only turning over a compiled binary of the application? Or would you insist that he provide the source?

> > Unsubstantiated bunk, if you have the source code, it is not magic to
> > fix it, or extend it, just normal progamming.

> Right. So, if I do CAD programming, why should I learn database programming
> only to support a dead database? It's much easier to migrate to another one.

Why are you struggling so hard with such simple logic?

• If a Dead Database means your application is also dead, if migration is impossible; having source code can save the day.
• If migration is possible, migrating is easier with abstraction.
• If you have source *AND* you have abstracted, whoa nelly, you are in *really* good shape.
• If your data is archived in a self contained, self describing, human readable format, why, you are all but invincable.

Thus my advice.

> Besides, have you considered that quite a few open source projects get abandoned
> because they have become unmaintainable?

And closed-source applications have never been abondoned???

Another simple question: If your application is abandoned, are you in better shape with, or without source code?

> Anyone remembers hurd? Groff?

Yeah, what about them?

> What was the last gmake improvement? And if the authors throw up their hands,
> what can I do? Ask my boss to form a department for the beating of dead
> horses?

If you are dependent on them, at least you always have the source code and can thus continue to use the product, even have it modified if you need to.

If, however, you are dependent on a closed-source dead horse, well, you are horse-shit out of luck.

> > Simple calling something
> > an illusion does not explain why you condsider it impossible to
> > actually change a program. Perhaps you should consider a different
> > line of work.

> Oh, it's pretty easy to change a program. Working through millions
> of lines of code and repairing it with less time or money than it would
> cost to migrate to another database is the trick.

Reminder: I am an the one advocating Abstraction, which would make it easier to migrate to another database. What the hell are you talking about?

And If, for some reason, you *must* repair the database, say the bug is simple and is easier to fix than to migrate a large working implemtation, at least with the source, you can, without the source you can not.

> Convincing the customer to
> install *my* database version is another, particularly if three or four
> developers do this.

Leaving the customer stranded because your application is hosed by an obsoleted dependency is even a harder sell.

> > > Same question: Did you read what I wrote?
> >
> > A better question: What kind of an idiot are you that, in the face of
> > good sense, the best you can do is attemp insulting, evasive
> > rehetoric?

> It's not a better question. You keep bringing up that stupid
> source code argument totally ignoring the fact that it simply doesn't
> work, at least not for the money a normal support contract costs.

You keep basing your entire argument on nonsencical out-of-hand dismissals, like 'it simply doesn't work.'

It does work, let me let you into a little secret: programmers modify source code, that's how programs are made and fixed. Without source code you can not fix a program.

> And if support doesn't work, I still won't support it on my own.

You can do what you want, my advice is just that, advice, many people are in different situtations from you, and have a different point of view.

> > As I said, my comments where ment *FOR DEVELOPERS* that is those who
> > are developing *NEW* appliciations, and my advice is simple enough,
> > despite your contortions: If your application is important to you, do
> > not engineer a dependency on code you do not have access to.'

> Do you develop for platforms other than linux?

Yes, I have and do develop for many platforms, but *I* am not the topic of this thread, despite your desperation. Once again, you only attack the arguer because you have no argument.

The assertion you quote remains true, and your response, as usual, is not a response at all.

> > More unsubstantiated bunk, first of all, in many cases you can hire
> > the original developers,

> Yeah, exactly. A man year here costs about USD200000,-. A support
> contract with oracle costs me about a tenth of that.

In many cases you can aquire a support contract from corporations that have the original developers working for them.

> And even if I buy some incident based support contract, there is still
> no difference from an incident based support contract with oracle.

Yes there is, since you value the original developers so highly, we'll try this example.

The best original developer of Oracle, the one with the greatest knowledge of the system and code, quits Oracle and goes to work for Databases-R-Us, since you have no source, you must continue to deal with Oracle, the copyright holder, and can not hire Databases-R-Us, who employ the developer.

The best original developer of MySQL, the one with the greatest knowledge of the system and code, quits MySQL AB and goes to work for Databases-R-Us, since you do have source, you no longer need to deal with MySQL AB, the copyright holder, and can instead, choose Databases-R-Us, who employ the developer.

Just one simple example of how having the source gives you more freedom, and how the developer and the copyright holder are not the exact same thing, to say nothing of the support peon they actually let you talk to.

> As long as that guy exists and I can sue him into doing his job I don't
> need the source code (he needs) and otherwise I have no one to
> replace him.

Suing him is a red herring. You applicaion is not powered by law suits, but rather by compiled source code.

> But thanks for acknowleding that reliable support costs money.

If stating the obvious is somehow of help to you, you're welcome.

> > regardless of your right to the source code,
> > secondly, by hiring the "Copyright Holders" you *ARE NOT NECESSARLIY
> > HIRING THE DEVELEORS*, who may not even be with the company anymore,
> > in fact you are often hiring some peon who they scooped of the
> > consulting market 5 minutes before sending him to your office as an
> > certified solutions prodiver or whatever idiotic buzzword whey have
> > for their unskilled labour.

> Try it.

Try what? The paragraph you are quoting explains the difference between original developer and copyright holder, what are you suggesting I try?

> Besides, remember, the company has an interest in providing
> support because they live off it.

They also have an interest in dumping relationships that are no longer profitable, and may not be interested in your obscure problem or implemention, but rather more interested in selling you (or someone else) something new.

Other organisations may be quite interested in helping you, but are unable to because you have no source code for them to fix.

> > And finaly, it is a falalcy to say that someone will do a worse job
> > simply because they are not the original developer.

> So, if I pick some average application programmer off the street,

> how long do you think it takes before he can start smoothing
> out bugs in the postgres optimizer?

I would not recomed you 'pick some average application programmer off the street' if you want to sort a bug in the postgres optimizer.

Many developers could do whatever you want, for instance: PostgreSQL, Inc (not to be confused with PostgreSQL Org), Cybertec Geschwinde & Schoenig, NuSphere, or many others which know the system well.

However when Oracle lets you talk to a programmer, that is just who they let you talk to, some average programmer they picked off the street, the good programmers in their organisations to not work in the support department, but rather on new features for new versions and products to sell.

> > But it stops short of guaranting that your apllication will actualy
> > work,

> Of course they don't offer that. But they offer to put effort
> in it.

Only as long as it is profitable for them and no more, then you get 'Desupported'

> And they are dependent from me for my money.

Just you?

> > or that your existing version of the software will be supported.

> They provide upgrades and desupport dates. Ok, they do
> what I pay for.

Only as long as you pay, and only on their terms, if you have source, you need not change a working system just because it is not supported by Oracle anymore.

> > In anycase, I am not arguing agianst using Oracle, as I said, if
> > Oracle suits your needs and you think it's worth the money, use it,
> > however, my advice is that if you do develop an application, write
> > your code in such a way that you do not depend on Oracle, but can
> > easily switch it over the the greatest extent possible.

> Why "the greatest extent"? That costs me more time and money
> and customers that it's worth.

Because it will save you time and money in the long run in many cases, but it is, like everything else a case by case call, I was not trying to make design decisions for you or anybody else, just giving some advice, good advice, I have no idea what you are trying to do other than be a crank.

> Just look at informix to see how
> it goes when a db disappears from the market:
> They had a big market share, market share dwindled, they got weak
> and sold themselves to ibm because that's better than going bancrupt.
> Now IBM handles the migration to db2 and supports me as application
> developer in porting my app to db2. This is much better than handing
> me the source code and telling me that from now on I have to develop
> all the new features and fix bugs on my own or simply buy a new db
> and do the migration on my own.

Or instead of IBM they could have been bought by CA, and fucked up royaly. Or just been allowed to disapear. Again, you are depending on good luck and good graces, if you have source, you know for sure, but as I've said many times, it's even better to have an abstracted application.

And by the way, don't think that IBM is above squeezing these newly aquired hostages for every penny they are worth, and tosing aside the ones who helping would not be profitable. You dont become a 100 billion dollar company by being stupid.

> > I have no idea why you are insisting on jumping up and down like this
> > is crazy talk, the only plausible theory is that you get some kind of
> > thrill out of embarassing yourself.

> Where do I jump up and down?

When you stoop to making ridiculous, incoherent, awkward streches of logic to keep this conversation going on and on in the face of clearly explained, good advice.

> > This is just stupid, elegnt coding is hardly as unatainable an ideal
> > as you seem to be conviced, in fact in this specific case it's a
> > simply matter of using a standard wrapper function throughtout your
> > aplication to access your data rather than using proprietary bindings
> > throughout your application, if your application is sufficently
> > complicated, perhaps a data abstaction object might be usefull for
> > this function, perhaps not, if you use any non standard features of
> > your database server, then write some additional functions as wrappers
> > for these. It is anything but rocket science.

> So you have defined "elegant" as "abstraction" and expect the rest
> of the programmers to agree that that's it?
> Thanks for solving that problem for the rest of the world.

Se here is a good example of your jumping up and down waving around a fallacy a s if it was a point.

I did no such thing, I only explain what an elegent solution might be //in this specific case// just as it says.

I never claimed to solve the general problem of elegent coding for the rest world, this is just you wildly contorting yet again.

> > What about the human and financial load? As in the load on the DBA,
> > inhouse developers, consulting budgets and application support staff?

> The load on the DBA depends on the problems the application makes.
> That typical increases if the application ignores load reducing features for > the sake of being generic

And so does constantly changing everything to support differnet databases when he finds your unabstarcted application does not use the database that all his other applications do.

> This creates an excessive amoung of simple
> queries and lots of network traffic. Right now we have huge problems
> getting an application to work properly that claims to support mysql and
> oracle.

There are bad application out there, including ones that are Abstracted, and ones that are not.

> They could have done half the app in PL/SQL and saved 90%
> of the network and client load.

And locked themselves out of the portion of the market which does not use PL/SQL, but rather something else, or simply does not want to bear the cost that using PL/SQL adds to the product not only on implementation, but also in anual licencing and support costs.

> Also, if the database is not the standard one (because you have
> fixed/improved it) I have, at the worst, maintain two independent
> installations,

No, you only have to maintain the one you actuall have in production.

> As for consulting, we pay a flatrate for db support, so we unload as much
> of our problems on the oracle people. Works fine.

Just because it works fine sometimes, in some cases, does not mean that it works fine in all cases, my advice was generic, I am not anti-Oracle.

In most cases it does not make sence to build your application to depend on Oracle, or any thing else, exclusively. However there are certainly worse products to be dependant on, MS SQL for example.

> Ditto for support staff. Our users have oracle, so the more we make the db do
> the less problems we have in our own code.

Your specific case is not neccesarily the general or even common case.

> > Are you having a nightmare in which we are dicussing the various
> > merits of MySQL versus Oracle? Please follow your own advice and read
> > this thread again so that you might figure out what is it we are
> > actually taking about.

> We are talking about open source versus commercial databases.

Again, if by 'We' you mean some imaginary person the rest of can't see or hear, please ignore my intrusion, however if you mean You and I, we are not.

We are talking about two different things, the advantages of source, and the advangates of abstarction of access, I have made no comments in this thread regarding commercial versus open source databases except to agree that the commercial ones _do_ have more features, that alone however does not always
make them the best choice.

> I picked
> those two as examples because I have worked with both of them.

Great, sadly however, not relevent.
 
> > More straw men and red herrings. If you are a Developer, which is who
> > my comments are addressed to, it is your responsiblilty to your users
> > and clients to know how your application works and to be able to
> > support it without allowing some third party to hold them hostage.

> No one holds anyone hostage. I let people do what they are good at.
> I'm ok with application programming in the CAD world. Oracle (or
> IBM, or microsoft) are good at programming databases. So, I
> profit from their expertise by being able to provide a better application
> than if I had to do db development (or fixing) as well.

However, a closed source contract is designed to hold you hostage, and to keep competitors away.

> So far no one has complained.

No one you know is not no one.

> > because Database security can only depend on it, not being able to
> > actualy protect devices, which is the burden on the OS and networking
> > environment.

> The os protects devices, not the network. Or, daring to think the
> unthinkable,

The OS is a part of Network security, what manages user priviledges? The Switch? What controls device permissions? Your ethernet cables?

Your network security is a product of the collection of OSes that make up the nodes of your network. And the network is exactly as secure as the weakest node.

> do you mean that you consider it ok to have database data on nfs mounts?

See, you have just provided an example of how bad network security can undermine good database security, there are plenty of others as well.

My point, once again, is that you can only have Database security, *IF* you have a secure network, which means that the nodes on it are secure.

> > What does reading text files have to do with Chip design?

> Because some tool will have to parse the text and create the chip out of it.

Yes, that tool being the Application, the very thing following my advice will help you protect. Also, not all data is about creating chips, in many cases the data is the purpose of the appliction, and can outlive it, sometimes it must, by law, be accessible for a really really long time, like in the case of public data, as I said. In this case in particular, keeping your data in a self contained, self describing, human readable file format is good sence. That is why things like XML and dublin core get invented.

It's unfortunate that you can not see the value of something simply because you it is not needed for your specific application, and waste my time and yours trying to convice me that because you do not need it, I shouldn't recomend it to anyone, and by doing so I prove that I am inexperienced, however many years of experience I may or may not have.

> This tool typically costs in the range of USD100000-200000 for a synopsys
> ASIC compiler. You need the same tool because any other tool creates
> totally different designs, ignores the original constraints and rules and
> uses a different library which may even force a complete redisign.
> Compared to that, a database migration is truly a breeze.

Then your data does not have a long life span, so why are you presenting it as an argument, when my advice was specificly qualified to "ensure the perminancy and portabilty of your important data?"

If your data does not need to be either perment nor portable, why are you discussing this, do you really imagine that because you data does not need to be permenent or portable, that therefore no data needs to be?

> > I can read
> > text files I created on my Apple ][, and no, I do not have the orginal
> > hardware (well maybe my mom does somewhere in her basement).

> Not all textfiles are notices for you to read.

Yet some are, and for this data my advice holds true, I have never implied that all data must be kept accessable forever, rather advising on what to consider when it does.

> > Which ones? That abstracting access to suspect dependencies is a good
> > idea?

> That elegance is abstraction.

The quote says "That abstracting access to suspect dependencies is a good idea" not "elegance is abstraction"

Here you are jumping up and down again.

> > That database security is secondary to network security?

> Yes.

It is, if you ask a security expert you will find they agree with me.

> > That
> > one should keep archives in a format that is likely to be readable
> > forever?

> Yes.

Instead, archives should be kept in a format that can not be readable forever? What do you think archives are for? I don't mean simple backups.

> Those are the tree main reasons. The fourth one is your persistent
> belief that the right to the source code is of value.

The right to source code is very much of value in many cases, even if it's not of value to you.

You still have demonstrated nothing about my experience, which you still know nothing about. And your insisting on having pretentions of being more experienced than me only help you make an ass of yourself.

> > All these things come from experience,

> So, what migrations have you done so far?

As I've said, I'll rather leave my arguments speak for themselves rather than be drawn into a pissing contest about who has done more migrations. Since having done more migrations would not make me automaticaly correct.

As I've already tried to explain to you, an argument that attacks the arguer instead of the argument is a fallacy.

When I attack you, it is purely for the fun of it, I refute your arguments by addressing them directly.

> Right now I'm in the process of doing two, one boing our board design
> toolchain, with plenty of data translation and the other a business flow app.
> So far we've spent at least four man years on the CAD flow and it's far
> from over. As for the other, try to imagine having a small busines flow
> tool and then introducing SAP companywide.
> And we get migration support from the new vendor.
> Believe me, a database migration is *EASY* compared to that.
> Even if I hardwire OCI calls into my c-code and then switch to
> ODBC or something.

You mean the same SAP that developed the Open Source SAP DB and is now working with MySQL DB in making it MaxDB? Did you not tell them that source is of no value? Think of all the effort you could have saved them! Forunatly there customers, who value their data, told them different.

In anycase, I'm not intersted in what you are working on. It's irrelevent and it sounds banal. Nor does it in anyway strengthen your arguments.

> > your attempt to question my
> > experience, only show that you are unable to formalute an actual
> > argument, so you try and discredit the arguer instead of the argument.

> I did. You just didn't understand it.

Yeah, sure. I don't understand your arguments. They are incomprehensible nonsence.

> > Oh please, my argument has been presented well enough, attacking me
> > just shows you can not defend your own, that is if you actually had
> > one.

> You might have noticed that you got responses from different people

And I responded in kind, if one of them made an argument you feel I didn't address well enough, feel free to quote it, although I am happy you feel a sence of support from MS SQL shills.

> whereas you are the only one who thinks my arguments are rubbish.

How do you know what everybody thinks? you think what is posted in this thread represent what everyone thinks?

> Now, statistics is not fact, but it's evidence and should get you thinking.

Better evidence is how easily all your arguments are refuted.

> > If my argument was not backed up by anything it would easy enough to
> > refute it without attempting to insult me,

> I don't insult you I'm trying to get through to you.

Thanks, from now on I will never abstract my database access, ignore network security, refuse to accept source code for any dependency of my applications, insist on being locked in to single source for all my support contracts and always, always keep my archives in an incoprehensible filesystem blob that I can only access by way of a third party, closed-source deamon.

Now that you have educated me on the fact that law suits and not source code is what I should depend on, I will give up my long career as a developer and begin training to be a lawyer.

You've really set me straight.

I bow before your awesome experience.

> Reasonable arguments didn't work.

Always ready to go beyond the call of duty for a good cause, huh?

> > These must be voices in your head that you are hearing. Since my
> > argument have been quite clear and even sumerized several times.

> Yes. The right to source code balances nonexisting support and
> buying support for a open source software (instead of trying to
> fix things oneself) is somehow better than doing the same with
> commercial software. Did I leave out anything important?

Yes, my entire argument, but dont let that stop you from blathering.

> > Your arguments amount to the metaphysical belief that only the
> > copyright holders of your favourite proporiety software know how to
> > program,

> No, that they are the only ones that should be allowed because they
> are the only ones that can take responsibility.

See, "the only ones that can," -- they posses a special metaphysical quality that no one else posses. Interesting faith you have.

> > that the very concept of good programming is an illussion,

> No, it's just that so far no one has found out what it is, because
> despite all the attempts software still is not substantially more stable
> than software written 30 years ago.

So we should not try to write good programms then? Quick, someone tell Don Knuth.

> > and therfore the only way forward is to make yourself both tehnicaly
> > and legaly dependent on them as much as possible.

> You forget that they depend on me. Namely, on my money.

God help them then.

Fortunatly there are other customers.

> > > So, oracle people should further develop oracle and mysql people
> > > mysql. Did I get this right?
> >
> > No, that's not right, that's not even wrong.

> So, what is it?

A non sequitor, a red herring, a straw man, a fallacy, irrelevent, what it isn't is a response to my argument, neither a right, nor a wrong response.

> > Application developers should avoid locking themselves in to external
> > dependencies, either by not using products to which they have no right
> > to the source code, or abstracting access when they do use such
> > products. Simple.

> There it is again, this source code right thingie. And you complain about me
> getting rude.

I don't complain, go ahead and serve, I'll snap. I like dozens. I just wonder why you're such a glutten for punishement.

> Again: The source code is no guarantee of fixed bugs, much less improvements.

Again: Not having source is a guarantee that one CAN NOT fix bugs.

> It's not even what I want.

Yet others may not want what you want, do you think that my advice was directed at you and your application specifically?

> I also can go and tinker with the airbag of my car
> if I think it's broken, I don't do that either but go to a repair shop.

Yes, and just like software, your financing contract may allow you to go to any repair shop, or even fix it yourself if you are able to, or it may force you into only using the repair shop of the dealer. The later, by the way, is sometimes a rip off.

> And if you are worrying about expiring licences, for many products
> (purify and our oracle installation spring to mind) you get permanent
> licences and pay yearly for support, so I can still use the app when the
> vendor goes bust.

Who will fix the bugs when the vendor goes bust? Or compile it for your new OS, or your new CPU? Or to link a updated library for which there is a security patch?

> And before you come again about the source code I can fix and improve,
> or pay someone to do it, I won't because that would be wasting company
> money and that would be because a migration is cheaper than tinkering with
> the old software and it wouldn't lose us customers either because customers
> When we figured out that our new CAD tool doesn't support oracle 9.2
> we gave them a ding behind the ear and, see, the next release, out
> in two months supports it and til then we got a workaround.
> don't like dead software.

You just do whatever you want, I'm sick of talking to you, however surely you must know that not everyone agrees with you, even if you haven't noticed that, your reasoning is based on nothing substantial but your insistances and pretentions, even so you are entitiled to hold your goofy ideas. Good luck to you. Just dont bore me with what you want, or what you do, or anything about you at all, or me for that matter, stick to the topic or go away.

And trim your posts better, you don't need to quote every line in the previous post, only the ones you actually respond to.

> > And having right to the source code does not mean that the program is
> > 'open source,' as you can purchace such a right for propretary code,
> > as is common for libraries.

> And still, if something goes wrong, I file a service request.
> And if the company does ceases to offer the product I change company.

Sometimes it's best to change companies and keep the product, sometimes it's best to abstract your code to make changing products easier. What is your point exactly?

> > "Assitance" only means that they will provide someone whose time they
> > can bill you for,

> As I said, we pay a flatrate.

And you get what you pay for, do not imagine they will consent to losing money on you for long if their costs go above your flat rate.

> > not that anything will be accomplished.

> Then they lose money if they don't accomplish anything.

Right, if fixing it costs them more that what you are paying them, then they desupport you, and you, not having source code can not find someone who can (or will) do it cheaper, and you, thinking that database access abstraction is a waste of time, must change your entire application. Have fun. Your systems and data may have a short enough life span that this works for you, do not assume that this is the case for all applications and all data.

> > Many large companies, and profesional develpoers provide source
> > licences and/or support open source products, including the largest
> > computer company in the world, IBM.

> Yep, so I can buy support, mess up the code I've access to and let
> IBM sort it out, is this what I get by using a IBM supported mysql?

Who is the developer, you or IBM? If you are hiring IBM, why are you messing with the code? I'm sure, if you are willing to pay them enough, IBM corporate services will indulge this crazy plan of yours, but they will probably at least suggest you decide wether it is you *OR* them who are developing the code, and if you already have screwed it up, perhaps they might prefer to start with a fresh copy from MySQL AB.

But anyway, this is nothing more than you jumping up and down again making ludicrous examples.

> If not, what's the difference to buying db2 support?
> (One thing more: No, if IBM abandons mysql I'm still not taking
> on the support task, ok?)

IBM corporate services will not abondon anything as long as you keep paying, heck, this is the company that created VisaulAge Cobol and CICS for NT, however if you do have source, you can get someone else to take over if you chose. But I know, source code is useless, good programming is a myth, data abstraction a waste of time, readable file formats are for novices, and network security is nothing but humbug. Thanks for enlightening us all. I'm sure you think normalized data models are for pussies too.

Regards,
Dmytri Kleiner
Wide eyed heretic, who believes tabs are better than spaces, does not have a preference between Emacs or vi, yet actually thinks coding standards matter. Go figure. Received on Wed May 12 2004 - 19:14:02 CDT