Generalnie nie ma nie minusem używania text pod względem wydajności/pamięci. Wręcz przeciwnie:text jest optymalny. Inne typy mają mniej lub bardziej istotne wady. text jest dosłownie "preferowanym" typem wśród typów łańcuchowych w systemie typów Postgres, co może wpływać na rozdzielczość funkcji lub typu operatora.
W szczególności nigdy użyj char(n) character(n) char lub char są po prostu skrótem od character(1) , więc wszystko jedno. Nazwa wewnętrzna to bpchar (oznacza „znak z wypełnieniem pustym”). Typ jest tam tylko dla zgodności ze starym kodem i standardami. W dzisiejszych czasach ma to bardzo mało sensu, marnuje pamięć i może powodować problemy:
- Porównaj varchar z char
- Długość pola tekstowego w Postgres SQL
Możesz użyć varchar(n) z modyfikatorem długości (alias dla character varying(n) ). Ale varchar(255) (255) nie ma specjalnego znaczenia i rzadko ma sens.
- Czy powinienem dodać dowolny limit długości do kolumn VARCHAR?
Starsze wersje powodowały różne problemy podczas próby zmiany modyfikatora długości varchar(n) później. Większość z nich została złagodzona we współczesnym Postgresie, ale text lub varchar (alias dla character varying ) bez specyfikatora długości (i CHECK ograniczenia zamiast tego) nigdy nie miał żadnego z tych problemów.
CHECK ograniczenie jest tak samo szybkie i mniej prawdopodobne, że spowoduje problemy z zależnymi widokami, funkcjami, ograniczeniami FK itp., które zależą od typu kolumny. I może zrobić coś więcej niż tylko wymusić maksymalną długość znaków — wszystko, co można umieścić w wyrażeniu logicznym. Zobacz:
- Zmień kolumny PostgreSQL używane w widokach
Wreszcie jest też "char" (z podwójnymi cudzysłowami):1-bajtowy typ danych dla pojedynczej litery ASCII używany jako tani typ wewnętrznego wyliczenia.
Rzadko używam czegokolwiek poza text dla danych znaków w Postgresie.
