Vastus (19.10.2023 20:29): Kui CHAR(n) tüüpi veerus salvestatakse tekstiline väärtus, mis on lühem kui n märki, siis lisatakse salvestamisel väärtuse lõppu tühikud, et saavutada maksimaalne lubatud stringi pikkus. VARCHAR(n) tüüpi veeru korral seda ei tehta.

PostgreSQL oskab paljude operatsioonide korral CHAR(n) tüüpi väärtuse lõppu lisatud tühikuid ignoreerida. Tühikuid ei ignoreerita stringi mustrile vastavuse kontrollimisel. Seega LIKE, ILIKE, SIMILAR TO ja regulaaravaldisele vastavuse kontrolli operaatorite kasutamisel tekitab CHAR(n) tüüpi veerg probleeme.

Kuna CHAR(n) tüübi korral lisatakse stringi lõppu tühikuid, siis kulub sellisel juhul rohkem salvestusruumi.
CHAR ja VARCHAR tüüpi veergudes olevate andmetega operatsioonide tegemisel ei ole märkimisväärset töökiiruse erinevust.

Deklaratsioon CHAR on samaväärne kui deklaratsioon CHAR(1)
Deklaratsioon VARCHAR on samaväärne kui deklaratsioon TEXT

Ainukene põhjus eelistada veeru tüübina CHAR(n) kasutamist VARCHAR(n) kasutamisele on anda andmebaasi skeemi kasutajale märku (vihjata), et selles veerus on oodatud ühesuguse pikkusega (n-märki) stringid. Näiteks veeru deklaratsioon riik_kood CHAR(3) võiks anda lugejale märku, et selles veerus on oodatud alati täpselt kolme märgi pikkused koodid.

Samas sõltumata sellest, kas veerg riik_kood on CHAR(3) või VARCHAR(3) tüüpi, tuleb reegli "kood koosneb täpselt kolmest suurtähest" andmebaasis jõustamiseks luua täiendav CHECK kitsendus. Vastasel juhul saab registreerida koode nagu "123" "!?" "aa ".

SIIN on katsetus ja koodinäited, mis eelnevate väidete paikapidavust illustreerivad.