Re: more anti-postgresql FUD - Mailing list pgsql-general

From Tim Tassonis
Subject Re: more anti-postgresql FUD
Date
Msg-id 452D6FCE.2020908@cubic.ch
Whole thread Raw
In response to Re: more anti-postgresql FUD  (Steve Crawford <scrawford@pinpointresearch.com>)
Responses Re: more anti-postgresql FUD  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-general
Steve Crawford schrieb:
> Guy Rouillier wrote:
>> Andrew Sullivan wrote:
>>> On Tue, Oct 10, 2006 at 02:50:44PM -0400, Tom Lane wrote:
>>>> Some days I think database independence is a myth.
>>> On the day when you don't, please tell me what application you found
>>> where it isn't.  I want to buy the developers a drink.  Or maybe a
>>> bar.
>> The Mantis bug tracking software http://www.mantisbt.org/ now works with
>> PostgreSQL (was developed with MySQL.)  It works equally well with both,
>> including automated installation.
>>
>
> I find that "database independence" == "lowest common denominator". I
> may have missed something, but a quick scan of the Mantis code didn't
> reveal any use of triggers, rules, foreign-keys, user-defined types, etc.

Well, that is hardly surprising. What exactly is your point?

If you want to write portable software, you usually stay with generally
available, standardized features or API's, be it "database independent",
"platform independent", you name it. You certainly don't go for
user-defined types. I really think all the nice features and
capabilities of PostgreSQL are great, but I would never, ever start
using any of them extensively in a project that might have to run on
another database. Ever heard of vendor lock-in and "embrace and expand"?

>
> Whenever I see that a project has been "ported" to PostgreSQL I can
> usually be sure that it is not a project that was designed to take
> advantage of the features and capabilities that PG offers.
>
> But I suspect that porting something that uses all the features of mySql
> to PostgreSQL will be far easier than porting something that uses all
> the features of PostgreSQL over to mySql (if it is possible at all).

You're certainly right here (I did this before), that's why a lot of
projects can support PostgreSQL when they started off with mySql. You
can bet that isn't the case with projects that started off with Oracle
(care to rewrite a few hundred triggers, packages and statements?).

Bye
Tim

>
> Cheers,
> Steve
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend


pgsql-general by date:

Previous
From: stig erikson
Date:
Subject: CUBE, ROLLUP, GROUPING SETS?
Next
From: Ron Johnson
Date:
Subject: Re: question on renaming a foreign key