PostgreSQL to MySQL schema differences

[Lennart Sorensen]

On Mon, Nov 21, 2005 at 05:09:51PM -0500, Madison Kelly wrote:
> Hi all,
> 
>   I am trying to get MySQL working on my backup program which, so far, 
> only runs on PostgreSQL. I suspect this will be fine because I just use 
> basic SQL calls (no stored procedures and such).
> 
>   My question is, my schema file I use to load the tables and data into 
> the database on pgSQL doesn't work on MySQL (surprise). Is there any 
> documentation on what is different between mysql and pgsql? I've been 
> reading the MySQL docs (for v4.1) and I've learned how to create 
> databases and users and such but I can't find anything on what is and is 
> not valid. For example:
> 
> CREATE TABLE schedule (
> 	sch_dom			text		default '*',
> 	...
> );
> 
>   works on pgsql but fails on mysql saying:
> 
> ERROR 1101 (42000) at line 67: BLOB/TEXT column 'sch_dom' can't have a 
> default value
> 
> 
>   If there is a central document or whatever on what is and is not 
> allowed I'd be quite happy. :)
> 
> Thanks all!

Maybe this would be of use to you:

Package: dbconfig-common
Priority: optional
Section: admin
Installed-Size: 824
Maintainer: sean finney <seanius-8fiUuRrzOP0dnm+yROfE0A at public.gmane.org>
Architecture: all
Version: 1.8.7
Depends: ucf, pwgen, debconf (>= 0.5) | debconf-2.0
Suggests: virtual-mysql-client | mysql-client | postgresql-client
Filename: pool/main/d/dbconfig-common/dbconfig-common_1.8.7_all.deb
Size: 112842
MD5sum: 2edec010d0a538c6d6435a7d25afcea2
Description: common framework for packaging database applications
 dbconfig-common presents a policy and implementation for
 managing various databases used by applications included in
 debian packages.
 .
 dbconfig-common can:
  * support mysql and postgresql based applications
  * create databases and database users
  * access local or remote databases
  * upgrade/modify databases when upstream changes database structure
  * remove databases and database users
  * generate config files in many formats with the database info
  * import configs from packages previously managing databases on their own
  * prompt users with a set of normalized, pre-translated questions
  * handle failures gracefully, with an option to retry.
  * do all the hard work automatically
  * work for package maintainers with little effort on their part
  * work for local admins with little effort on their part
  * comply with an agreed upon set of standards for behaviour
  * do absolutely nothing if it is the whim of the local admin
  * perform all operations from within the standard flow of debian
    package maintenance (no additional skill is required of the local
    admin)

Lennart Sorensen
--
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