Over het algemeen is er geen nadeel van het gebruik van text qua prestaties/geheugen. Integendeel:text het optimum is. Andere typen hebben min of meer relevante nadelen. text is letterlijk het "voorkeurstype" onder stringtypes in het Postgres-typesysteem, wat van invloed kan zijn op de functie of de resolutie van het operatortype.
In het bijzonder nooit gebruik char(n) character(n) char of character zijn gewoon een afkorting voor character(1) , dus allemaal hetzelfde. De interne naam is bpchar (staat voor "blanco opgevuld karakter"). Het type is er alleen voor compatibiliteit met oude code en standaarden. Het heeft tegenwoordig weinig zin, verspilt geheugen en veroorzaakt waarschijnlijk problemen:
- Vergelijk varchar met char
- Stringveldlengte in Postgres SQL
U kunt varchar(n) . gebruiken met lengtemodificator (alias voor character varying(n) ). Maar varchar(255) (255) heeft geen speciale betekenis en is zelden zinvol.
- Moet ik een willekeurige lengtelimiet toevoegen aan VARCHAR-kolommen?
Oudere versies veroorzaakten verschillende problemen bij het wijzigen van de lengtemodifier van varchar(n) later. De meeste daarvan zijn verholpen in het moderne Postgres, maar text of varchar (alias voor character varying ) zonder lengtespecificatie (en een CHECK beperking) nooit een van deze problemen gehad.
EEN CHECK beperking is net zo snel en zal minder snel problemen veroorzaken met afhankelijke weergaven, functies, FK-beperkingen enz. die afhankelijk zijn van het kolomtype. En het kan meer doen dan alleen een maximale tekenlengte afdwingen - alles wat je in een booleaanse uitdrukking kunt zetten. Zie:
- Verander PostgreSQL-kolommen die worden gebruikt in weergaven
Ten slotte is er ook nog "char" (met dubbele aanhalingstekens):een gegevenstype van 1 byte voor een enkele ASCII-letter die wordt gebruikt als goedkoop intern enumeratietype.
Ik gebruik zelden iets anders dan text voor karaktergegevens in Postgres.