Re: Help with PostgreSQL porting project - Mailing list pgsql-general

From Arjen van der Meijden
Subject Re: Help with PostgreSQL porting project
Date
Msg-id 3FF56225.90207@vulcanus.its.tudelft.nl
Whole thread Raw
In response to Re: Help with PostgreSQL porting project  (Enver ALTIN <enver.altin@frontsite.com.tr>)
Responses Re: Help with PostgreSQL porting project  (Enver ALTIN <enver.altin@frontsite.com.tr>)
List 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



pgsql-general by date:

Previous
From: Enver ALTIN
Date:
Subject: Re: Help with PostgreSQL porting project
Next
From: Enver ALTIN
Date:
Subject: Re: Help with PostgreSQL porting project