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