一般的な問題：
- GROUPBYの動作。 PostgreSQLにはかなり厳密なGROUPBYがあります。 GROUP BY句を使用する場合は、SELECTのすべての列をGROUP BYに表示するか、集計関数で使用する必要があります。
- データの切り捨て。 MySQLは、
char(n)内に収まるように長い文字列を静かに切り捨てます。 サーバーが厳密モードでない限り、PostgreSQLは文句を言い、文字列を自分で切り捨てさせます。 - 引用は異なります。MySQLは識別子の引用にバッククォートを使用しますが、PostgreSQLは二重引用符を使用します。
- LIKEは、MySQLでは大文字と小文字を区別しませんが、PostgreSQLでは大文字と小文字を区別しません。これにより、多くのMySQLユーザーは、大文字と小文字を区別しない文字列等価演算子としてLIKEを使用するようになります。
（1）ARのgroupを使用すると問題になります 任意のクエリのメソッドまたは任意の生のSQLのGROUPBY。 column "X" must appear in the GROUP BY clause or be used in an aggregate function いくつかの例と一般的な解決策が表示されます。
（2）アプリケーションのどこかで文字列列を使用し、モデルがすべての長さを適切に検証していない場合、問題になります。 着信文字列値。制限を指定せずにRailsで文字列列を作成すると、実際にはvarchar(255)が作成されることに注意してください。 列なので、実際には暗黙の:limit => 255 指定しなかったとしても。別の方法は、t.textを使用することです t.stringの代わりに文字列に;これにより、ペナルティなしで任意の大きな文字列を操作できます（少なくともPostgreSQLの場合）。アーウィンが以下に記しているように（そして彼が得る他のすべてのチャンス）、varchar(n) PostgreSQLの世界では少し時代錯誤です。
（3）コードに生のSQLが含まれていない限り、問題にはなりません。
（4）アプリケーションのどこかでLIKEを使用している場合は、問題になります。これは、a like bを変更することで修正できます。 lower(a) like lower(b) （またはupper(a) like upper(b) 叫びたい場合）またはa ilike b ただし、PostgreSQLのILIKE
に注意してください。 非標準です。
トラブルを引き起こす可能性のある他の違いがありますが、それらは最も一般的な問題のようです。
安全を感じるには、いくつかのことを確認する必要があります。
group呼び出します。- 未加工のSQL（
whereのスニペットを含む 呼び出し）。 - モデルでの文字列の長さの検証。
- LIKEのすべての使用。