Umumnya, tidak ada tidak kelemahan menggunakan text dalam hal kinerja/memori. Sebaliknya:text adalah yang optimal. Jenis lain memiliki kelemahan yang kurang lebih relevan. text secara harfiah adalah tipe "pilihan" di antara tipe string dalam sistem tipe Postgres, yang dapat memengaruhi resolusi tipe fungsi atau operator.
Khususnya, tidak pernah gunakan char(n) character(n) char atau character kependekan dari character(1) , jadi semua sama. Nama internalnya adalah bpchar (singkatan dari "karakter dengan bantalan kosong"). Jenisnya hanya ada untuk kompatibilitas dengan kode dan standar lama. Sangat tidak masuk akal saat ini, membuang-buang memori dan cenderung menyebabkan masalah:
- Bandingkan varchar dengan char
- Panjang bidang string di Postgres SQL
Anda dapat menggunakan varchar(n) dengan pengubah panjang (alias untuk character varying(n) ). Tapi varchar(255) (255) tidak memiliki arti khusus dan jarang masuk akal.
- Haruskah saya menambahkan batas panjang sewenang-wenang ke kolom VARCHAR?
Versi lama menyebabkan berbagai masalah saat mencoba mengubah pengubah panjang varchar(n) nanti. Sebagian besar telah dikurangi di Postgres modern, tetapi text atau varchar (alias untuk character varying ) tanpa penentu panjang (dan CHECK kendala) tidak pernah mengalami masalah ini.
CHECK kendala sama cepat dan kecil kemungkinannya untuk menyebabkan masalah dengan tampilan tergantung, fungsi, kendala FK dll yang bergantung pada jenis kolom. Dan itu dapat melakukan lebih dari sekadar menegakkan panjang karakter maksimum - apa pun yang dapat Anda masukkan ke dalam ekspresi boolean. Lihat:
- Ubah kolom PostgreSQL yang digunakan dalam tampilan
Terakhir, ada juga "char" (dengan tanda kutip ganda):tipe data 1-byte untuk satu huruf ASCII digunakan sebagai tipe enumerasi internal yang murah.
Saya jarang menggunakan apa pun selain text untuk data karakter di Postgres.
