Elenco di cose che farei diversamente:
MEDIUMINT in MySQL è un'anatra dispari (3 byte). Lo eviterei, ma altrimenti lo mapperei anche su INTEGER.
MySQL BOOLEAN (alias BOOL, alias TINYINT(1) ) non è compatibile con il tipo pg boolean. Potresti o meno essere in grado di trasferire le app a seconda di ciò che usano come valori letterali booleani. In MySQL, TRUE e FALSE si associano a valori interi 1 e 0. Sembra che il tipo pg BOOLEAN utilizzi la notazione letterale stringa. Quindi le app possono essere portatili o meno, almeno non si tratta di sostituzioni.
Infine, per l'ultima riga della tua tabella, penso che la frase SQLite dovrebbe essere:
INTEGER PRIMARY KEY AUTOINCREMENT
Questo è più o meno equivalente a
BIGINT PRIMARY KEY AUTO_INCREMENT
in MySQL. In postgres, il tipo di dati SERIAL risulta in una colonna INTEGER, e questo sarà più o meno lo stesso di MySQL
INTEGER PRIMARY KEY AUTO_INCREMENT
Postgres ha anche un tipo BIGSERIAL, che è lo stesso di SERIAL ma con un tipo BIGINT invece di un tipo INT.
Cosa mi sono perso:
Mi manca INTEGER (alias INT) per MySQL. È paragonabile a INTEGER in pg. Omissioni molto importanti:VARCHAR e CHAR. Semanticamente, VARCHAR in MySQL e PG e CHAR in MySQL e PG sono gli stessi, ma in MySQL questi tipi hanno una lunghezza massima molto più breve. In MySQL questi tipi possono avere un massimo di poco meno di 64kb, in pg 1Gb (byte). L'identificatore della lunghezza effettiva è espresso nel numero di caratteri, quindi se si dispone di un set di caratteri multibyte, è necessario dividere la lunghezza massima per il numero massimo di caratteri per ottenere la lunghezza massima teorica specificata per quel set di caratteri. In SQLite, VARCHAR e CHAR mappano entrambi su TEXT
I tipi di dati BIT in MySQL e PG hanno più o meno la stessa semantica, ma in MySQL la lunghezza massima del tipo di dati BIT è 64 (bit)
Penso che il tipo di dati MySQL VARBINARY sia meglio paragonabile al tipo di dati BYTEA di PG. (ma in effetti anche i tipi BLOB di MySQL si associano a quello)
Il tipo FLOAT in MySQL dovrebbe essere equivalente a REAL in postgres (e anche REAL in SQLite) Il tipo DECIMAL in MySQL è equivalente a DECIMAL in postgres, tranne per il fatto che in postgres il tipo non impone un limite arbitrario alla precisione, mentre in MySQL la precisione massima è (credo) 70. (cioè 70 posizioni numeriche) Sia per MySQL che per Postgres, NUMERIC è un alias per il tipo DECIMAL.
