Geralmente, não há não desvantagem de usar
text em termos de desempenho/memória. Ao contrário:text é o ideal. Outros tipos têm desvantagens mais ou menos relevantes. text é literalmente o tipo "preferido" entre os tipos de string no sistema de tipos Postgres, o que pode afetar a resolução do tipo de função ou operador. Em particular, nunca use
char(n) character(n) char ou character são abreviações de character(1) , então tudo igual. O nome interno é bpchar (significa "caractere preenchido em branco"). O tipo existe apenas para compatibilidade com códigos e padrões antigos. Faz muito pouco sentido hoje em dia, desperdiça memória e provavelmente causará problemas:- Compare varchar com char
- Tamanho do campo de string no Postgres SQL
Você pode usar
varchar(n) com modificador de comprimento (alias para character varying(n) ). Mas varchar(255) (255) não tem significado especial e raramente faz sentido. - Devo adicionar um limite de comprimento arbitrário às colunas VARCHAR?
Versões mais antigas causavam vários problemas ao tentar alterar o modificador de comprimento de
varchar(n) mais tarde. A maioria deles foi aliviada no Postgres moderno, mas text ou varchar (alias para character varying ) sem especificador de comprimento (e um CHECK restrição) nunca teve nenhum desses problemas. Um
CHECK restrição é tão rápida e menos provável de causar problemas com visualizações, funções, restrições FK etc. dependentes que dependem do tipo de coluna. E ele pode fazer mais do que apenas impor um comprimento máximo de caractere - qualquer coisa que você possa colocar em uma expressão booleana. Ver:- Alterar as colunas do PostgreSQL usadas nas visualizações
Finalmente, há também
"char" (com aspas duplas):um tipo de dados de 1 byte para uma única letra ASCII usada como tipo de enumeração interna barata. Eu raramente uso algo além de
text para dados de caracteres no Postgres. 
