Document COPY TO limitation for control characters in text columns

COPY TO does not support control characters in text column values per
RFC 4180. This patch documents the limitation in the cqlsh reference,
including the security risks and alternative tools for data migration.

patch by Arvind Kandpal; reviewed by Brad Schoening, Stefan Miklosovic for CASSANDRA-21415

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
This commit is contained in:
Arvind Kandpal 2026-06-01 12:53:44 +05:30 committed by Stefan Miklosovic
parent 50960a2e7e
commit 36b23cba1f
No known key found for this signature in database
GPG Key ID: 32F35CB2F546D93E
1 changed files with 13 additions and 0 deletions

View File

@ -461,6 +461,19 @@ value `STDOUT` (without single quotes) to print the CSV to stdout.
See `shared-copy-options` for options that apply to both `COPY TO` and
`COPY FROM`.
[NOTE]
====
`COPY TO` exports CSV using a restricted RFC 4180-compatible format and does not
preserve control characters in text column values. Text columns containing control characters
such as newlines (`\n`), carriage returns (`\r`), null bytes (`\x00`),
or other non-printable characters cannot be reliably exported — values
will be corrupted on re-import via `COPY FROM`. Beyond data integrity,
non-printable characters in CSV output can pose security risks, including
CSV injection and other forms of malicious data embedding. If your data
contains such characters, consider using DSBulk, Spark, or
`sstableloader` for data migration instead.
====
==== Options for `COPY TO`
`MAXREQUESTS`::