I allmänhet finns det nej nackdelen med att använda text vad gäller prestanda/minne. Tvärtom:text är det optimala. Andra typer har mer eller mindre relevanta baksidor. text är bokstavligen den "föredragna" typen bland strängtyper i Postgres-typsystemet, vilket kan påverka funktion eller operatörstypupplösning.
I synnerhet aldrig använd char(n) character(n) char eller character är bara kort för character(1) , så ändå. Det interna namnet är bpchar (står för "blank-padded karaktär"). Typen finns endast där för kompatibilitet med gamla koder och standarder. Det är väldigt lite vettigt nuförtiden, slösar bort minne och kommer sannolikt att orsaka problem:
- Jämför varchar med char
- Strängfältslängd i Postgres SQL
Du kan använda varchar(n) med längdmodifierare (alias för character varying(n) ). Men varchar(255) (255) har ingen speciell betydelse och är sällan vettigt.
- Ska jag lägga till en godtycklig längdgräns för VARCHAR-kolumner?
Äldre versioner orsakade olika problem när man försökte ändra längdmodifieraren för varchar(n) senare. De flesta av dessa har lindrats i modern Postgres, men text eller varchar (alias för character varying ) utan längdspecifikation (och en CHECK begränsning istället) har aldrig haft några av dessa problem.
En CHECK begränsning är lika snabb och mindre sannolikt att orsaka problem med beroende vyer, funktioner, FK-begränsningar etc. som beror på kolumntypen. Och det kan göra mer än att bara tvinga fram en maximal teckenlängd - allt du kan lägga i ett booleskt uttryck. Se:
- Ändra PostgreSQL-kolumner som används i vyer
Slutligen finns det också "char" (med dubbla citattecken):en 1-byte datatyp för en enda ASCII-bokstav som används som billig intern uppräkningstyp.
Jag använder sällan annat än text för teckendata i Postgres.