En general, no inconveniente de usar text en términos de rendimiento/memoria. Por el contrario:text es el óptimo. Otros tipos tienen inconvenientes más o menos relevantes. text es literalmente el tipo "preferido" entre los tipos de cadenas en el sistema de tipos de Postgres, lo que puede afectar la resolución del tipo de función o de operador.
En particular, nunca usa char(n) character(n) char o character son simplemente la abreviatura de character(1) , así que todo lo mismo. El nombre interno es bpchar (significa "carácter relleno en blanco"). El tipo solo existe por compatibilidad con el código y los estándares antiguos. Tiene muy poco sentido hoy en día, desperdicia memoria y es probable que cause problemas:
- Comparar varchar con char
- Longitud del campo de cadena en Postgres SQL
Puede usar varchar(n) con modificador de longitud (alias para character varying(n) ). Pero varchar(255) (255) no tiene un significado especial y rara vez tiene sentido.
- ¿Debería agregar un límite de longitud arbitrario a las columnas VARCHAR?
Las versiones anteriores causaron varios problemas al intentar cambiar el modificador de longitud de varchar(n) luego. La mayoría de ellos han sido aliviados en Postgres moderno, pero text o varchar (alias para character varying ) sin especificador de longitud (y un CHECK restricción en su lugar) nunca tuvo ninguno de estos problemas.
UN CHECK La restricción es igual de rápida y es menos probable que cause problemas con las vistas, funciones, restricciones FK, etc. que dependen del tipo de columna. Y puede hacer más que solo imponer una longitud máxima de caracteres:cualquier cosa que pueda poner en una expresión booleana. Ver:
- Cambiar las columnas de PostgreSQL utilizadas en las vistas
Finalmente, también está "char" (con comillas dobles):un tipo de datos de 1 byte para una única letra ASCII utilizada como tipo de enumeración interna económica.
Raramente uso algo más que text para datos de caracteres en Postgres.
