In genere, non svantaggio dell'utilizzo di text in termini di prestazioni/memoria. Al contrario:text è l'ottimo. Altri tipi hanno svantaggi più o meno rilevanti. text è letteralmente il tipo "preferito" tra i tipi di stringa nel sistema dei tipi Postgres, che può influire sulla risoluzione del tipo di funzione o operatore.
In particolare, mai usa char(n) character(n) char o char sono solo l'abbreviazione di character(1) , quindi lo stesso. Il nome interno è bpchar (sta in primo piano "carattere vuoto"). Il tipo è presente solo per compatibilità con il vecchio codice e standard. Al giorno d'oggi non ha molto senso, spreca memoria ed è probabile che causi problemi:
- Confronta varchar con char
- Lunghezza del campo stringa in Postgres SQL
Puoi utilizzare varchar(n) con modificatore di lunghezza (alias per character varying(n) ). Ma varchar(255) (255) non ha un significato speciale e raramente ha senso.
- Devo aggiungere un limite di lunghezza arbitrario alle colonne VARCHAR?
Le versioni precedenti causavano vari problemi durante il tentativo di modificare il modificatore di lunghezza di varchar(n) dopo. La maggior parte di questi è stata alleviata nel moderno Postgres, ma text o varchar (alias per character varying ) senza specificatore di lunghezza (e un CHECK vincolo invece) non ha mai avuto nessuno di questi problemi.
Un CHECK vincolo è altrettanto veloce e meno probabile che causi problemi con viste, funzioni, vincoli FK ecc. dipendenti che dipendono dal tipo di colonna. E può fare molto di più che imporre una lunghezza massima dei caratteri, qualsiasi cosa tu possa inserire in un'espressione booleana. Vedi:
- Cambia le colonne PostgreSQL utilizzate nelle viste
Infine, c'è anche "char" (tra virgolette):un tipo di dati a 1 byte per una singola lettera ASCII utilizzata come tipo di enumerazione interna a basso costo.
Raramente uso qualcosa tranne text per i dati dei personaggi in Postgres.
