Re: Help with PostgreSQL porting project

From: Arjen van der Meijden <acmmailing(at)vulcanus(dot)its(dot)tudelft(dot)nl>
To: Enver ALTIN <enver(dot)altin(at)frontsite(dot)com(dot)tr>
Cc: Chris Travers <chris(at)travelamericas(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Help with PostgreSQL porting project
Date: 2004-01-02 12:20:53
Message-ID: 3FF56225.90207@vulcanus.its.tudelft.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Enver ALTIN wrote:

> Hi,
>
> On Fri, 2004-01-02 at 13:38, Chris Travers wrote:
>
>>A few years ago, I set about porting a PHP application from MySQL to
>>PostgreSQL, after realizing that MySQL wasn't going to be able to handle it.
>>In order to do this, I built a light, fast database abstraction layer which
>>conforms to the behavior of the MySQL functions in PHP. This means that a
>>large amount of porting work could be made simple using this porting layer
>>if the application was originally used PHP's native MySQL functions rather
>>than a standard porting layer. The application was originally released
>>under the GPL.
>
>
> I guess it might bother you when people ask this but, what made you do
> the hardwork while it's already been done by several other projects like
> PHP ADODB and PEAR?
Are those two LIGHT weight?

Afaik, PEAR (DB) affects the performance of your OO-php-app quite bad,
but I haven't really tested it very often myself, just seen tests by others?
And I'm not talking "quite bad, because php is not very fast in OO", I'm
talking "quite bad, compared to other (custom built, light weight,
simple) OO abstraction layers".

Maybe that has changed since then? But I have, for that reason, never
really started using PEAR...

Best regards,

Arjen

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Enver ALTIN 2004-01-02 12:39:27 Re: Help with PostgreSQL porting project
Previous Message Enver ALTIN 2004-01-02 12:01:11 Re: Help with PostgreSQL porting project