Tenemos quince caracteres de nueva línea incrustados en el campo de un archivo S3 de origen. El tamaño del campo en la tabla de destino en Redshift es VARCHAR(5096) . La longitud del campo en el archivo fuente es de 5089 bytes. Estamos escapando cada uno de los quince caracteres de nueva línea con una barra invertida \ como lo requiere la opción ESCAPE del comando de copy . Nuestra expectativa con la opción ESCAPE es que la barra invertida \ que hemos insertado antes de cada carácter de nueva línea se ignore antes de cargar el objetivo en Redshift. Sin embargo, cuando usamos el comando copy con la opción ESCAPE estamos obteniendo
err_code:1204 - La longitud de la cadena excede la longitud DDL".
¿Hay alguna forma en que los caracteres de barra invertida \ no se cuenten para las cargas de columnas de destino en Redshift?
Nota: Cuando truncamos el campo de origen anterior en el archivo a 4000 bytes e insertamos la barra invertida \ antes de los caracteres de nueva línea, el comando de copy con la opción ESCAPE cargó correctamente el campo en Redshift. Además, los caracteres de barra invertida \ no se cargaron en Redshift como se esperaba.
Extiende en frío la longitud de VARCHAR para permitir más caracteres.
O bien, puede usar las opciones TRUNCATECOLUMNS para cargar tanto como sea posible sin generar un error.
Nuestro entendimiento de que el problema anterior era incorrecto. Las barras invertidas "\" que habíamos insertado no causaban el error "err_code:1204 - La longitud de la cadena excede la longitud de DDL". La opción "escape" con el comando de copia en realidad no contaba los caracteres de barra invertida insertados hacia el límite objetivo y también los eliminaba del valor cargado correctamente.
El problema real al que nos enfrentábamos era que algunos de los caracteres que intentábamos cargar eran caracteres UTF8 multibyte. Dado que suponíamos incorrectamente que tenían una longitud de 1 byte, el tamaño del campo objetivo estaba demostrando ser insuficiente. Aumentamos la longitud del campo objetivo de varchar(5096) a varchar(7096), después de lo cual todos los datos se cargaron correctamente.