別の方法で行うことのリスト：
MySQLのMEDIUMINTは奇妙なアヒル（3バイト）です。私はそれを避けますが、そうでなければINTEGERにもマップします。
MySQL BOOLEAN（エイリアスBOOL、エイリアスTINYINT（1））は、pgブール型と互換性がありません。ブールリテラルとして使用するものに応じて、アプリを移植できる場合とできない場合があります。 MySQLでは、TRUEとFALSEは1と0の整数値にマップされます。 pgBOOLEAN型は文字列リテラル表記を使用しているようです。そのため、アプリは移植可能である場合とそうでない場合があります。少なくとも、代替品のドロップはありません。
最後に、表の最後の行について、SQLiteのフレーズは次のようになっていると思います。
INTEGER PRIMARY KEY AUTOINCREMENT
これは、
とほぼ同等です。BIGINT PRIMARY KEY AUTO_INCREMENT
MySQLで。 postgresでは、SERIALデータ型はINTEGER列になり、これはMySQLの
とほぼ同じになります。INTEGER PRIMARY KEY AUTO_INCREMENT
PostgresにはBIGSERIALタイプもあります。これは、SERIALと同じですが、INTタイプではなくBIGINTタイプを使用しています。
見逃したこと：
MySQL用のINTEGER（別名INT）がありません。これは、pg.Veryimportantの省略：VARCHARおよびCHARのINTEGERに相当します。意味的には、MySQLとPGのVARCHAR、およびMySQLとPGのCHARは同じですが、MySQLではこれらのタイプの最大長ははるかに短くなっています。 MySQLでは、これらのタイプは1Gb（バイト）で最大64kb弱になる可能性があります。実際の長さ指定子は文字数で表されるため、マルチバイト文字セットがある場合は、最大長を最大文字数で割って、その文字セットに指定された理論上の最大長を取得する必要があります。 SQLiteでは、VARCHARとCHARは両方ともTEXT
にマップされますMySQLとPGのBITデータ型のセマンティクスはほぼ同じですが、MySQLではBITデータ型の最大長は64（ビット）です
MySQL VARBINARYデータ型は、PGのBYTEAデータ型に最もよく匹敵すると思います。 （ただし、実際にはMySQLのBLOBタイプもそれにマップされます）
MySQLのFLOATタイプはpostgresのREAL（およびSQLiteのREAL）と同等である必要があります。MySQLのDECIMALタイプはpostgresのDECIMALと同等ですが、postgresではタイプが精度に任意の制限を課さない点が異なります。 MySQLの最大精度は（私が信じている）70です。（つまり、70の数値位置）MySQLとPostgresの両方で、NUMERICはDECIMAL型のエイリアスです。