Obecně platí, že ne nevýhodou použití text z hlediska výkonu/paměti. Naopak:text je optimum. Jiné typy mají více či méně relevantní nevýhody. text je doslova „preferovaný“ typ mezi typy řetězců v systému typu Postgres, což může ovlivnit rozlišení funkce nebo typu operátora.
Zejména nikdy použijte char(n) character(n) char nebo character jsou jen zkratky pro character(1) , takže stejně. Interní název je bpchar (představuje "prázdný znak"). Typ je tam pouze kvůli kompatibilitě se starým kódem a standardy. V dnešní době to nedává příliš smysl, plýtvá to pamětí a pravděpodobně způsobí potíže:
- Porovnejte varchar s char
- Délka pole řetězce v Postgres SQL
Můžete použít varchar(n) s modifikátorem délky (alias pro character varying(n)). ). Ale varchar(255) (255) nemá žádný zvláštní význam a jen zřídka dává smysl.
- Mám do sloupců VARCHAR přidat libovolný limit délky?
Starší verze způsobovaly různé problémy při pokusu o změnu modifikátoru délky varchar(n) později. Většina z nich byla zmírněna v moderním Postgresu, ale text nebo varchar (alias pro character varying ) bez specifikátoru délky (a CHECK omezení) nikdy neměl žádný z těchto problémů.
A CHECK omezení je stejně rychlé a méně pravděpodobné, že způsobí potíže se závislými pohledy, funkcemi, omezeními FK atd., které závisí na typu sloupce. A umí víc než jen vynutit maximální délku znaku – cokoliv, co můžete vložit do booleovského výrazu. Viz:
- Změňte sloupce PostgreSQL používané v zobrazeních
Nakonec je tu také "char" (s dvojitými uvozovkami):1bajtový datový typ pro jedno písmeno ASCII používaný jako levný typ interního výčtu.
Málokdy používám něco jiného než text pro znaková data v Postgresu.