Working (basic) PgSQL->MySQL converted (was: Re:PostgreSQL to MySQL schema differences)

Andrew Hammond ahammond-swQf4SbcV9C7WVzo/KQ3Mw at public.gmane.org
Fri Nov 25 22:52:39 UTC 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23-Nov-05, at 08:21, Madison Kelly wrote:

> Joseph Kubik wrote:
>
>> If you find a good guide to this problem for "the application  
>> developer" please let me know.
>> I have some similar needs, and I see this issue becoming more  
>> important, not less.
>> -Joseph-

Summary of differences between RDBMSs:
http://troels.arvin.dk/db/rdbms/

Reasons not to touch MySQL:
http://sql-info.de/mysql/gotchas.html

You can find an analogous Postgres gotchas page on the same site. The  
nature of the difference between these two documents is informative.

> Well, I wouldn't call it 'good' by any stretch of the imagination  
> but the first working version of the PostgreSQL -> MySQL converter  
> is available for download now:
>
> http://tle-bu.org/download.html
>
> As Christopher mentioned, there are a lot of function is PostgreSQL  
> that are not supported by MySQL. Obviously those functions can't be  
> converted directly but if you are in the boat I am, writting a  
> program to use multiple DBs, you've probably got the funky function  
> in your code directly.

Although there are more functions in Postgres, as well as procedural  
languages and ways to define your own functions, what Chris was  
talking about is functionality. In terms of functionality, comparing  
MySQL to Postgres is like comparing a unicycle to an 5 ton dump truck.

The next issue raised is typically performance. The analogy I  
typically offer here is MS IIS vs UNIX/Apache. IIS can serve static  
pages slightly faster than Apache. But who cares? Static content  
isn't very interesting anymore. Similarly, with databases, it is  
common to see benchmarks which fail to address critical issues such  
as concurrency, and query complexity. Worse, they are typically  
generic designs which fail to take advantage of any features which  
are not common to all the databases being examined. This is clearly  
leads to misleading results.

> If your PostgreSQL database sticks to mostly stock SQL calls the  
> converter should work. As it is I can use the converted to change  
> my stock 'postgres.schema' file to a 'mysql.schema' file that will  
> load into MySQL properly.

Supporting multiple database platforms can make sense for  
applications which make only trivial use of the database. Beyond  
that, it becomes design for the lowest common denominator.

http://www.powerpostgresql.com/Downloads/database_depends_public.swf

__________________________________________________
Andrew Hammond    416-673-4138    ahammond-swQf4SbcV9C7WVzo/KQ3Mw at public.gmane.org
Data Services Group Manager, Afilias Canada Corp. Ltd.
CB83 2838 4B67 D40F D086 3568 81FC E7E5 27AF 4A9A

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDh5W4gfzn5SevSpoRAnwsAJ9dmJSVR2j2G2cqt+S1qSe7D2v3uQCfapCs
Pl7bmeJIQ42ZYhDlNaBDrZg=
=U7f5
-----END PGP SIGNATURE-----
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list