Lista över saker jag skulle göra annorlunda:
MEDIUMINT i MySQL är en udda anka (3 byte). Jag skulle undvika det, men annars mappa det till INTEGER också.
MySQL BOOLEAN (alias BOOL, alias TINYINT(1) ) är inte kompatibel med den booleska typen pg. Du kanske eller kanske inte kan porta appar beroende på vad de använder som booleska bokstaver. I MySQL mappar TRUE och FALSE till 1 och 0 heltalsvärden. Det ser ut som att pg BOOLEAN-typen använder bokstavlig strängnotation. Så appar kan vara bärbara eller inte - det är åtminstone ingen ersättning.
Slutligen, för den sista raden i din tabell tror jag att SQLite-frasen bör läsa:
INTEGER PRIMARY KEY AUTOINCREMENT
Detta motsvarar ungefär
BIGINT PRIMARY KEY AUTO_INCREMENT
i MySQL. I postgres resulterar SERIAL-datatypen i en INTEGER-kolumn, och detta blir ungefär samma som MySQL:s
INTEGER PRIMARY KEY AUTO_INCREMENT
Postgres har också en BIGSERIAL-typ, som är samma som SERIAL men med en BIGINT-typ istället för en INT-typ.
Vad jag missade:
Jag saknar INTEGER (alias INT) för MySQL. Det är jämförbart med INTEGER i sid. Mycket viktiga utelämnanden:VARCHAR och CHAR. Semantiskt är VARCHAR i MySQL och PG, och CHAR i MySQL och PG desamma, men i MySQL har dessa typer en mycket kortare maxlängd. I MySQL kan dessa typer ha maximalt lite mindre än 64kb, i pg 1Gb (byte). Den faktiska längdspecifikationen uttrycks i antalet tecken, så om du har en multi-byte teckenuppsättning måste du dividera den maximala längden med det maximala antalet tecken för att få den teoretiska maximala längden som anges för den teckenuppsättningen. I SQLite mappar VARCHAR och CHAR båda till TEXT
BIT-datatyperna i MySQL och PG har ungefär samma semantik, men i MySQL är den maximala längden på BIT-datatypen 64 (bitar)
Jag tror att MySQL VARBINARY-datatypen är bäst jämförbar med PG:s BYTEA-datatyp. (men faktiskt MySQL:s BLOB-typer mappar också till det)
FLOAT-typen i MySQL bör vara likvärdig med REAL i postgres (och REAL i SQLite också) DECIMAL-typen i MySQL är likvärdig med DECIMAL i postgres, förutom att i postgres sätter typen inte en godtycklig gräns för precisionen, medan i MySQL är den maximala precisionen (tror jag) 70. (det vill säga 70 nummerpositioner) För både MySQL och Postgres är NUMERIC ett alias för typen DECIMAL.