De lengtelimiet opgelegd door varchar(N) typen en berekend door de length functie is in karakters, niet in bytes. Dus 'abcdef'::char(3) wordt afgekapt tot 'abc' maar 'a€cdef'::char(3) wordt afgekapt tot 'a€c' , zelfs in de context van een database gecodeerd als UTF-8, waarbij 'a€c' is gecodeerd met 5 bytes.
Bij het herstellen van een dumpbestand klaagde dat 'Mér' zou niet ingaan op een varchar(3) kolom, die suggereert dat u een UTF-8-gecodeerd dumpbestand aan het herstellen was in een SQL_ASCII-database.
Ik deed dit bijvoorbeeld in een UTF-8-database:
create schema so4249745;
create table so4249745.t(key varchar(3) primary key);
insert into so4249745.t values('Mér');
En dit vervolgens gedumpt en geprobeerd het in een SQL_ASCII-database te laden:
pg_dump -f dump.sql --schema=so4249745 --table=t
createdb -E SQL_ASCII -T template0 enctest
psql -f dump.sql enctest
En ja hoor:
psql:dump.sql:34: ERROR: value too long for type character varying(3)
CONTEXT: COPY t, line 1, column key: "Mér"
Als ik daarentegen de database enctest maak als LATIN1 of UTF8 coderend, laadt het prima.
Dit probleem ontstaat door een combinatie van het dumpen van een database met een multi-byte tekencodering en het proberen deze te herstellen in een SQL_ASCII-database. Het gebruik van SQL_ASCII schakelt in feite de transcodering van clientgegevens naar servergegevens uit en veronderstelt één byte per teken, waardoor het aan de clients wordt overgelaten om verantwoordelijkheid te nemen voor het gebruik van de juiste tekenkaart. Aangezien het dumpbestand de opgeslagen tekenreeks als UTF-8 bevat, is dat vier bytes, dus een SQL_ASCII-database ziet dat als vier tekens en beschouwt het daarom als een schending van de beperking. En het drukt de waarde af, die mijn terminal vervolgens weer samenstelt als drie tekens.