По принцип не ест недостатък на използването на text по отношение на производителност/памет. Напротив:text е оптималното. Други видове имат повече или по-малко подходящи недостатъци. text е буквално „предпочитаният“ тип сред типовете низове в системата тип Postgres, което може да повлияе на разделителната способност на функция или тип оператор.
По-специално, никога използвайте char(n) character(n)). char или character са просто съкратени от character(1) , така че все едно. Вътрешното име е bpchar (означава "черно-подплатен знак"). Типът е там само за съвместимост със стария код и стандарти. В днешно време има много малко смисъл, губи памет и е вероятно да причини проблеми:
- Сравнете varchar с char
- Дължина на полето на низ в Postgres SQL
Можете да използвате varchar(n) с модификатор на дължина (псевдоним за character varying(n) ). Но varchar(255) (255) няма специално значение и рядко има смисъл.
- Трябва ли да добавя ограничение за произволна дължина към колоните VARCHAR?
По-старите версии причиниха различни проблеми при опит за промяна на модификатора на дължина на varchar(n) по късно. Повечето от тях са облекчени в съвременния Postgres, но text или varchar (псевдоним за character varying ) без спецификатор на дължина (и CHECK ограничение) никога не е имал нито един от тези проблеми.
A CHECK ограничението е също толкова бързо и по-малко вероятно да причини проблеми със зависими изгледи, функции, FK ограничения и т.н., които зависят от типа на колоната. И може да направи повече от просто да наложи максимална дължина на символа - всичко, което можете да поставите в булев израз. Вижте:
- Промяна на колоните на PostgreSQL, използвани в изгледите
И накрая, има и "char" (с двойни кавички):1-байтов тип данни за една ASCII буква, използвана като евтин вътрешен тип изброяване.
Рядко използвам нещо друго освен text за символни данни в Postgres.
