Help with PostgreSQL porting project

[Chris Travers]

Hi all;

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 am pleased to announce that I have been able to secure permission from all
contributors to be able to re-release this under the LGPL, so that it can be
used with non-GPL programs.

If there is interest in this project, please let me know.

Best Wishes,
Chris Travers
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Enver ALTIN]

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?

Just another curious guy from far side of the world,
Happy new year :)
--
__________
| |
| | Enver ALTIN (a.k.a. skyblue)
| | Software developer, IT consultant
| FRONT |
|==========| FrontSITE Bilgi Teknolojisi A.Þ.
|_____SITE_| http://www.frontsite.com.tr/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/9V2GZCB2FZvqK0s RAulPAJ4+e4kcih KiUMlf0M+1OOa8F 57lvQCghIud
PNgQaQ8WHY83eTK r4kLLNO8=
=2Ozb
-----END PGP SIGNATURE-----

[Arjen van der Meijden]

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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Enver ALTIN]

Hi,

On Fri, 2004-01-02 at 14:20, Arjen van der Meijden wrote:

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...

Please don't get me wrong, I've got an obsession like determining the
idea behind any free software project which I'm not really sure if it's
a good thing or not.

I'm not the only one who thinks there are way too many projects
duplicating each other (either completely or partially); wasting human
resources and motivation in both short and long term.

Just talking about PEAR::DB, you know, it's a generic database
abstraction layer which attempts to provide almost the same interface
for hopefully all databases supported by PHP; not only for PostgreSQL
and MySQL. It's no junk and it's something barely standardized and it's
bundled with official PHP distribution. In the end, it's free software.
I have noticed no performance bottlenecks in the past and even if there
was, I doubt there is a starving need for performance in web
applications. And I could be a good salesman so I'd better shut up :)

The term "lightweigh t" means barely nothing to me. Mozilla is FAT, but
most of us do use (at least parts of) it. PostgreSQL is not that
lightweight, you could use flat-files and POSIX API. For many cases,
weight is affordable, and we could possibly help it lose that fat by bug
reports.

BTW, you have not posted a URL for your work. Could you please do so, if
there is any? I would like to take a quick look at your code some time
this weekend.

Thanks for your patience for reading through the
stripped-from-good-ideas proven long text written by me.
Happy new year,
--
__________
| |
| | Enver ALTIN (a.k.a. skyblue)
| | Software developer, IT consultant
| FRONT |
|==========| FrontSITE Bilgi Teknolojisi A.Þ.
|_____SITE_| http://www.frontsite.com.tr/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/9WZ+ZCB2FZvqK0s RAp29AJ4hgqs8lI 2JCCyjY2q6K/xgfnWkaACfYgeD
wpV2Tt1wtb8DU3w YXHHwJro=
=xeGU
-----END PGP SIGNATURE-----

[Chris Travers]

Actually, I already had a few thousand lines of code done (using PHP's MySQL
functions) and I needed an abstraction layer to conform to my existing code.

In this case, if an application has been written with PHP's MySQL functions,
porting it to this layer would be simple and straightforward , with a minimum
of rewriting code (aside from, perhaps checking a few queries). Most of it
could be handled with search/replace facilities.

Even with a standard abstraction layer like PEAR or ADODB, the query syntax
is not identical between database managers. Although this is not nearly
perfect, I have attempted abstract over many of these differences (LIMIT
clauses, timestamp formats, etc.) The abstraction is not perfect but it
helps. A few additional functions could be written to better abstract some
of these things.

Basically these files contain a set of light-weight wrappers to facilitate
porting frim MySQL to PostgreSQL of PHP applications.

Basically, incompatibility comes from three things:
1: Incompatible data representation (aside from timestamps not handled by
most abstraction layers, including this one). However, some of these could
be better handled (such as BOOLs).

2: Incompatible function behavior (normally handled by any abstraction
layer)
For example PostgreSQL's return sets are not forward only, while MySQL's
are.

3: Query differences. For example, if I write:
SELECT * FROM customers ORDER BY last_name LIMIT 30 OFFSET 30
This will run on MySQL, but not PostgreSQL. I handled the difference in my
project by adding a function to generate limit clauses for given offsets and
limits. For RDBMS's that don't support offsets (MSSQL, Firebird), this
would be a bit more complex, but it could be done.

In other words, this is a simple API wrapper to make the db's behave the
same. It is NOT OO.

Best Wishes,
Chris Travers

----- Original Message -----
From: "Arjen van der Meijden" <ac********@vul canus.its.tudel ft.nl>
To: "Enver ALTIN" <en*********@fr ontsite.com.tr>
Cc: "Chris Travers" <ch***@travelam ericas.com>;
<pg***********@ postgresql.org>
Sent: Friday, January 02, 2004 7:20 PM
Subject: Re: [GENERAL] Help with PostgreSQL porting project

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 whichconforms to the behavior of the MySQL functions in PHP. This means that alarge amount of porting work could be made simple using this porting layerif the application was originally used PHP's native MySQL functions ratherthan 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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org