Re: MySQL -> pgsql - Mailing list pgsql-general

From Alex Pilosov
Subject Re: MySQL -> pgsql
Date
Msg-id Pine.BSO.4.10.10010192156510.22422-100000@spider.pilosoft.com
Whole thread Raw
In response to Re: MySQL -> pgsql  ("David Reid" <dreid@jetnet.co.uk>)
List pgsql-general
On Thu, 19 Oct 2000, David Reid wrote:

> OK.  Thanks to all who replied.  Here are my first impressions...
>
> - pgsql is fussier about names of columns than mysql.  e.g. a column name of
> position was rejected by pgsql but seems to be OK in mysql.
> - PRIMARY_KEY() syntax is OK for pgsql (which was a relief)
> - There seem to be a lot more types in mysql than pgsql.
>
> Questions that have cropped up already!!
>
> - can tinyint(4) be considered to be int4?
my script thinks that if its *int(1) to *int(4) it'll be replaced by int2,
if its *int(5) to *int(11), it'll be replaced by int4, otherwise numeric.

> - what should an int(11) be?
> - if it uses "int(11) DEFAULT 0 NOT NULL auto_increment" is that
> functionally the same as serial?
My script generates necessary functions to imitate mysql's behavior.
(i.e. value inserted will be one+maxval in table)

The _right_ way is of course, to use sequences, but they have a feature
that will sometimes (i.e. backed out transaction), you'll have some holes
in transactions...

> - is there an easy way to duplicate enums?  this is one of the ones I need
> to copy...
> "enum('R','L') DEFAULT 'R' NOT NULL"
My script is udderly stupid. if its enum(true,false), convert it to
boolean. otherwise, convert it to char(5). Feel free to modify it and do
it the proper way (at least char(proper size) with appropriate CHECK
clause).

I think you'll find that my script isn't easily modifiable...Since it
doesn't have a real parser, but just a hack that was written in an hour.
Proper fix would be to rewrite it using a mysql-ish grammar...but then
again, I had all my use of that script and all my data is now safely in
pgsql, and I don't need to use it ever again ;)

-alex



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: prefer (+) oracle notation
Next
From: Tom Lane
Date:
Subject: Re: oracle ambiguity, inline views