Topik ini membahas tiga jenis teks PostgreSQL, yaitu varchar, char, dan text, serta alasan text menjadi pilihan baku di dokumentasi resminya sendiri. Setelah topik ini, keputusan antara teks berbatas dan teks tanpa batas memiliki dasar teknis, bukan kebiasaan turun-temurun dari basis data lain.
Tiga jenis teks#
varchar tanpa argumen dan text berperilaku identik, keduanya menyimpan teks dengan panjang apa pun. varchar(n) menambahkan batas panjang yang ditegakkan server, sedangkan char(n) menyimpan teks berpanjang tetap yang dilapisi spasi. Ketiganya menghitung panjang dalam karakter, bukan byte, sehingga teks beraksara Latin diperluas dan teks beraksara lain tidak terpotong sembarangan.
Perbedaan batas panjang muncul dalam dua bentuk. Cast eksplisit ke varchar(n) memangkas nilai berlebih tanpa error, sedangkan pemasukan nilai berlebih ke kolom varchar(n) ditolak oleh server. Blok berikut memperlihatkan keduanya, dan psql melanjutkan ke pernyataan berikutnya setelah error baris keduanya.
# cast eksplisit memangkas, kolom varchar(n) menolak
psql -U postgres -d perpustakaan <<'SQL'
SELECT 'perpustakaan'::varchar(5) AS dipangkas;
CREATE TABLE uji_teks (kode VARCHAR(5));
INSERT INTO uji_teks VALUES ('perpustakaan');
DROP TABLE uji_teks;
SQL dipangkas
-----------
perpu
(1 row)
CREATE TABLE
ERROR: value too long for type character varying(5)
DROP TABLEKeluaran pertama menunjukkan cast eksplisit yang memangkas diam-diam menjadi lima karakter, sedangkan INSERT ke kolom ditolak dengan pesan yang menyebut tipenya. Pemangkasan diam-diam pada data produksi justru lebih berbahaya daripada error, sehingga cast eksplisit dengan batas panjang dipakai dengan sengaja dan penuh kesadaran. Satu perilaku lagi menyertai char(n), yaitu pelapisan spasi hingga panjang tetapnya yang dibuang kembali saat dibaca, sehingga length melaporkan panjang logisnya. Perilaku pelapisan ini sumber kejutan klasik pada perbandingan dan penggabungan, dan itulah alasan char(n) dipakai hanya untuk format berpanjang tetap yang memang menuntutnya.
text dan varchar tidak berbeda performa#
Di dalam PostgreSQL, text dan varchar disimpan melalui jalur yang sama, tanpa perbedaan kecepatan maupun ukuran. Dokumentasi resmi menyatakan hal ini terus terang, berbeda dari kebiasaan basis data lain yang memperlakukan varchar lebih efisien. Karena itu, aturan praktisnya jelas, yaitu memakai text, dan menambahkan batas varchar(n) hanya ketika batas itu sendiri adalah aturan bisnis yang perlu ditegakkan.
Batas panjang sebagai aturan bisnis sah dan berguna, misalnya kode pos yang wajib lima karakter. Yang tidak berguna adalah batas defensif seperti varchar(255) yang diturunkan dari kebiasaan basis data lama, karena batasnya tidak melindungi apa pun dan hanya menambah migrasi ketika suatu saat dilampaui.
Fungsi teks yang paling sering dipakai#
Setelah tersimpan, teks diolah dengan fungsi bawaan. Empat fungsi yang paling sering muncul adalah length untuk panjang, upper dan lower untuk kapitalisasi, serta trim untuk membuang spasi di kedua ujung.
# fungsi teks dasar pada satu ekspresi
psql -U postgres -d perpustakaan -c "SELECT upper('perpustakaan') AS besar, lower('PerpusTakaan') AS kecil, length('perpustakaan') AS panjang, trim(' perpus ') AS rapi;" besar | kecil | panjang | rapi
--------------+--------------+---------+--------
PERPUSTAKAAN | perpustakaan | 12 | perpus
(1 row)Penggabungan memakai operator || sebagaimana ditunjukkan topik DISTINCT dan ekspresi, sedangkan pemotongan dan pencarian pola memakai substring, position, dan LIKE. Daftar lengkapnya ada pada bab fungsi teks di dokumentasi resmi yang dirujuk di bagian akhir.
Kesalahan umum#
Kesalahan pertama adalah memilih varchar(255) dari kebiasaan, yang tidak memberi perlindungan dan hanya menunggu migrasi ketika data nyata melampauinya. Kesalahan kedua adalah mengira char(n) lebih cepat karena berpanjang tetap, padahal pelapisan spasinya justru menambah kompleksitas perbandingan. Kesalahan ketiga adalah menyimpan data terstruktur seperti JSON atau daftar bernilai koma di dalam kolom teks, sehingga query ke dalamnya memaksa penguraian string dan tidak dapat diindeks dengan layak, dan penggantinya adalah jsonb yang dibahas pada modul JSONB.
Kesalahan keempat adalah menghitung panjang dalam pikiran sebagai byte. Basis data ini menghitung karakter, sehingga teks beraksara Latin diperluas dan emoji yang menempati beberapa byte tetap dihitung sebagai satu atau dua karakter sesuai titik kodenya.
Ringkasan#
- varchar tanpa batas dan text identik di dalam PostgreSQL, dan text menjadi pilihan baku tanpa kehilangan performa.
- varchar(n) menegakkan batas panjang sebagai aturan bisnis, sedangkan char(n) melapisi spasi dan hanya cocok untuk format berpanjang tetap.
- Panjang dihitung dalam karakter, bukan byte, sehingga aksara apa pun aman dihitung dengan length.
- Data terstruktur tidak disimpan di kolom teks, melainkan memakai jenis data yang sesuai seperti jsonb.
Referensi#
- Character Types — PostgreSQL Documentation — Dokumentasi resmi varchar, char, dan text beserta catatan performanya.
- String Functions and Operators — PostgreSQL Documentation — Daftar fungsi teks bawaan.
- Collation Support — PostgreSQL Documentation — Pengaturan urutan dan kapitalisasi teks per bahasa.