feat: writable external tables (INSERT/LOAD into stage files)

[fengttt]

What

Make external tables writable. An external table created with a new
write_file_pattern option accepts INSERT ... SELECT and LOAD, writing
CSV or JSONLine files into a stage:// destination. The pattern is a
strftime(3) template with two MO extensions:

• %nN → n random decimal digits
• %U → a UUID

Each parallel write pipeline produces exactly one file. Reads, UPDATE/DELETE,
and read-only external tables are unchanged.

CREATE EXTERNAL TABLE t (a int, b varchar(20), c double)
INFILE{'filepath'='stage://s/part_*.csv', 'format'='csv',
       'write_file_pattern'='stage://s/part_%U.csv'}
FIELDS TERMINATED BY ',';

INSERT INTO t SELECT * FROM src;          -- writes one CSV file to the stage
LOAD DATA INFILE '...' INTO TABLE t ...;  -- same, from a source file

How

• pkg/sql/colexec/externalwrite (new): strftime expander, ExternalWriter
  with a fileservice streaming sink (io.Pipe), CSV/JSONLine encoders. Encoders
  are const-vector aware and emit only the table's declared columns.
• insert operator: third write mode ToExternal/insert_external alongside
  ToWriteS3/insert_table. Write config is carried on the Go InsertCtx
  built at compile time from TableDef.Createsql. The plan proto is unchanged; pipeline.Insert (proto) gained to_external + external_stmt_unix_nano so remote-run rebuilds the operator on the receiving CN.
• compile: compileInsert routes external-write nodes to one writer op per
  source scope (no S3 merge/shuffle) → one file per pipeline, parallel across CNs.
• planner: minimal external insert plan (build_insert/build_load);
  op-aware checkTableType allows writable-external for insert;
  initInsertStmt Pkey nil-guard (external tables have no PK); the modern DML
  binder defers external targets to the legacy planner.
• DDL: validates write_file_pattern (must be stage://, csv/jsonline only,
  pattern must parse) and accepts it in the read-side option validators.

Semantics / limitations

• Output formats: CSV and JSONLine only; destination must be stage://.
• Empty pipeline → no file (lazy file creation).
• Writes are not transactional (files are finalized at pipeline close); a
  failed statement may leave partial files. Documented as a v1 limitation.
• UPDATE/DELETE on external tables remain unsupported.

Tests

• Unit: pkg/sql/colexec/externalwrite (expander, encoders), build_ddl validator.
• BVT: test/distributed/cases/stage/writable_external_table.{sql,result} —
  CSV/JSONLine insert + readback, multi-file accumulation, LOAD into external,
  and all error cases. Passes 37/37 locally. Existing stage.sql (external reads
  • DML-rejection checks) still passes 100%.

Design + as-built notes: docs/design/writable_external_table_impl.md.

🤖 Generated with Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[fengttt]

Review round 2 (at 2f3365c) — 10 inline findings posted, focused on the code added across the fix rounds and on test coverage. Several were verified empirically against the actual csvparser (constructed inputs through the real tokenizer), not just by reading.

Severity picture: three P1s are silent-corruption bugs in validator/writer gaps (multi-char terminator boundary overlap — (10,5) reads back as (1,5) with TERMINATED BY '00'; ENCLOSED BY '\' sneaking past the conflict check; jsonline records split by custom printable line terminators). Four P2s are round-trip losses the reader forces (trailing \r truncation even in quoted fields; \N-literal strings becoming NULL under non-default escapes and always under jsonline; jsonline coercing invalid UTF-8 to U+FFFD; enum('NULL') and whitespace-edged bit values). One P2 covers statement-scoped config drift (prepared EXECUTE freezes the pattern timestamp; remote CNs render TIMESTAMPs in a year-1 LMT zone due to the session-info codec). Plus %1N entropy and a consolidated test-coverage finding.

Adjacent issues found but not filed inline (pre-existing, beyond this PR's scope — listing for visibility):

• ALTER TABLE <any external table> ADD/CHANGE/DROP COLUMN nil-derefs on tableDef.Pkey in buildAlterTable (external tables have no fake PK). Also means column-shape alters would bypass validateWriteFilePattern if the panic were fixed without a guard.
• TRUNCATE TABLE silently no-ops on external tables with success status — misleading now that writable tables hold INSERTed data.
• SHOW CREATE masks FILEPATH to '' for non-hive infile tables, so the emitted DDL recreates a write-only table; for stage:// paths the masking protects nothing. An empty stored JSONDATA is also accepted at CREATE but rejected at read.
• Maintainability: CSV-option defaulting now lives in three hand-synced copies (validator / buildExternalInsertArg / NewExternalWriter) — worth a single ResolveCSVOptions(tail); the REPLACE sentinel is matched by full message string across packages (a structural marker would be safer); WriterConfig.Header/writeCSVHeader/expandedPath/writer-side rowsWritten are dead or write-only; FileServiceWriter.Abort's Group.Wait can block teardown indefinitely on a hung backend (detaching the wait would bound it).

[XuPeng-SH]

I rechecked the latest head. The CSV option round-trip work looks much better, but one substantive issue still remains.

SHOW CREATE TABLE still drops the external table's read FILEPATH, so writable external tables are not actually recreatable from their own DDL.

formatInfileExternalOptionsForShowCreate() still hardcodes filepath := "" for non-Hive external tables and only preserves param.Filepath when HivePartitioning is true (pkg/sql/plan/build_show_util.go:960-975). The new BVT output still shows this exact problem on the writable-table cases, e.g. ext_csv and t_all both emit INFILE{'FILEPATH'='', ... 'WRITE_FILE_PATTERN'=...} (test/distributed/cases/stage/writable_external_table.result:13-15, test/distributed/cases/stage/writable_external_csv_options.result:260-262).

That means the shown DDL does not recreate the original table semantics: it preserves the write pattern, but loses the read glob. For writable external tables this is not just cosmetic, because SHOW CREATE TABLE is supposed to be re-executable and MatrixOne's snapshot/PITR/restore paths fetch table DDL via show create table (pkg/frontend/snapshot_restore_with_ts.go:252-268, pkg/frontend/pitr.go:1583-1592, pkg/frontend/snapshot.go:2072-2080). Replaying the downgraded DDL can silently turn a readable writable-external table into one with no read path at all.

I think this still needs to be fixed before approval: preserve the external table's FILEPATH in SHOW CREATE TABLE / restoreDDL for these writable tables, not only the WRITE_FILE_PATTERN.

[fengttt]

@XuPeng-SH Fixed in 3ab7a82 — you're right that with restore replaying SHOW CREATE output this stopped being cosmetic.

For external tables with a WRITE_FILE_PATTERN, formatInfileExternalOptionsForShowCreate now emits the real FILEPATH and omits empty optional keys (the second half mattered too: an embedded 'JSONDATA'='' was accepted at CREATE but rejected by the read-side validator, so even with FILEPATH restored the recreated table couldn't read). Read-only external tables keep the legacy masked output byte-for-byte, so no existing expectations outside this PR change.

Verified live on the cluster as a full loop: SHOW CREATE → drop → execute the emitted DDL verbatim → the recreated table reads the pre-existing stage files and accepts new writes — for both csv and jsonline (which emits its real JSONDATA='object'). The BVT now does the same: it recreates ext_csv and ext_jl from their emitted DDL mid-test and asserts the combined counts (3 → 6 → 9 across the recreation boundary), and unit tests pin both the writable form (FILEPATH present, no empty keys) and the unchanged read-only form.

[XuPeng-SH]

I found a few remaining unhappy-path/correctness blockers in the current head.

1. Compressed writable tables can be created, but the write path always emits plain bytes. validateWriteFilePattern accepts COMPRESSION='gzip' and compressed write-path suffixes, while buildExternalInsertArg/WriterConfig do not carry compression and externalWriter streams raw CSV/JSONLine. The read path later calls crt.GetUnCompressReader(..., param.Extern.CompressType, param.Fileparam.Filepath, ...), and crt.GetCompressType auto-detects suffixes like .gz/.bz2/.lz4 when compression is empty/auto. So a table can be created with a gzip compression setting or a .gz write pattern, INSERT can succeed, and then SELECT tries to decompress raw CSV/JSONLine and fails. Please either implement compression on the write path or reject writable external tables whose effective compression for produced files is not none.

2. CSV comment handling can corrupt valid writer output. External CSV readers always set Comment: '#', and csvparser.readRecord skips any row whose recordBuffer[0] == '#' after quotes are stripped but before unescape. The writer emits "#lost",1\n for a first-column string value '#lost', so the same table can silently drop the inserted row on readback. There is also a panic edge case here: if all fields are empty strings, e.g. ""\n or "",""\n, recordBuffer is empty and the comment check still indexes recordBuffer[0]. Please either disable comment processing for these external table reads, or make the writer/validator protect/reject the affected values; coverage should include leading # and all-empty string rows.

3. Writable DDL accepts CSV delimiter configs that the reader refuses at open time. For example, FIELDS TERMINATED BY '#' passes the new writable validation, but the actual CSV parser rejects it because the reader's comment marker is also #. Delimiters starting with invalid parser bytes such as newline, carriage return, or quote are the same class of issue. This means the table can be created and written, but any read fails before parsing. Writable DDL should mirror the parser delimiter validation or construct/check the parser config during validation.

4. Duplicate external options can make validation check a different configuration than the one later stored/executed. validateWriteFilePattern uses getRawOption, which returns the first format/jsondata, but the option initializers later walk the whole slice and later duplicates win. A table can therefore validate as format='csv' and then be stored/executed as format='parquet', causing runtime external write format "parquet" after CREATE succeeded. Duplicate jsondata can similarly validate as object but read as array. Please reject duplicate option keys relevant to writable external tables before validation/normalization.

[fengttt]

@XuPeng-SH Thanks — all four were real. Fixed in 71595e6, each verified live on the 2-CN cluster.

1. Compression. validateWriteFilePattern now rejects any effective compression: an explicit COMPRESSION option, or a .gz/.bz2/.lz4-class suffix auto-detected from either the read FILEPATH glob or the WRITE_FILE_PATTERN (mirroring crt.GetCompressType's decision, inlined to avoid a plan←crt import cycle). So COMPRESSION='gzip' and a *.csv.gz read glob and a %U.csv.gz write pattern are all rejected at CREATE.

2. CSV # comment. The reader hardcoded Comment: '#', dropping any first-column value starting with # (after quote-stripping, so enclosure couldn't save it) and risking an out-of-range recordBuffer[0] on an all-empty row. I disabled the comment marker for writable-table reads (detected via GetWriteFilePattern on the read param) — a #-leading value is now data and # becomes a usable separator — while read-only external tables keep # for backward compatibility. The parser's comment skip is also now guarded with len(recordBuffer) > 0 (fixes the panic for all readers). BVT round-trips #lead, an all-empty row, and a # separator.

3. Delimiter validation. A FIELDS TERMINATED BY whose first byte is a quote, CR, LF or NUL is rejected at DDL (mirroring the reader's validDelim/NewCSVParser). With the comment marker disabled for writable reads, # is now a legal field terminator and round-trips.

4. Duplicate option keys. validateWriteFilePattern now rejects duplicate format/jsondata/compression/filepath/write_file_pattern up front (reusing rejectDuplicateKeys), so validation and the last-wins read-side init can't disagree — no more validate-as-csv / run-as-parquet.

Unit tests cover the compression (option + read-suffix + write-suffix), duplicate-key, and terminator-byte cases, plus csvparser tests for the empty-record no-panic and comment-disabled paths. BVT: 160/160 + 123/123 locally.

[fengttt]

@XuPeng-SH Thanks — all four were real. Fixed in 71595e6, each verified live on the 2-CN cluster.

1. Compression. validateWriteFilePattern now rejects any effective compression: an explicit COMPRESSION option, or a .gz/.bz2/.lz4-class suffix auto-detected from either the read FILEPATH glob or the WRITE_FILE_PATTERN (mirroring crt.GetCompressType's decision, inlined to avoid a plan←crt import cycle). So COMPRESSION='gzip' and a *.csv.gz read glob and a %U.csv.gz write pattern are all rejected at CREATE.

2. CSV # comment. The reader hardcoded Comment: '#', dropping any first-column value starting with # (after quote-stripping, so enclosure couldn't save it) and risking an out-of-range recordBuffer[0] on an all-empty row. I disabled the comment marker for writable-table reads (detected via GetWriteFilePattern on the read param) — a #-leading value is now data and # becomes a usable separator — while read-only external tables keep # for backward compatibility. The parser's comment skip is also now guarded with len(recordBuffer) > 0 (fixes the panic for all readers). BVT round-trips #lead, an all-empty row, and a # separator.

3. Delimiter validation. A FIELDS TERMINATED BY whose first byte is a quote, CR, LF or NUL is rejected at DDL (mirroring the reader's validDelim/NewCSVParser). With the comment marker disabled for writable reads, # is now a legal field terminator and round-trips.

4. Duplicate option keys. validateWriteFilePattern now rejects duplicate format/jsondata/compression/filepath/write_file_pattern up front (reusing rejectDuplicateKeys), so validation and the last-wins read-side init can't disagree — no more validate-as-csv / run-as-parquet.

Unit tests cover the compression (option + read-suffix + write-suffix), duplicate-key, and terminator-byte cases, plus csvparser tests for the empty-record no-panic and comment-disabled paths. BVT: 160/160 + 123/123 locally.

2 is the wrong fix. This is a parser bug (old code) and should be fixed in the read path. Vibing it now.

[fengttt]

Correction on the CSV comment-marker fix (#2), now in d8b3806 — my earlier "disable comment for writable reads" was the wrong approach. Fixed the parser properly instead:

• Digging in, CSVConfig.Comment was accepted but never wired into the parser (dead code), and the check it would have done was on recordBuffer[0] after unquoting — which is exactly why an enclosed "#x" would have been dropped.
• CSVConfig.Comment is now a string, defaulting to empty = no comment marker, so every line is data. Both CSV callers (external read and LOAD DATA) default it empty — matching MySQL LOAD, which doesn't treat # lines as comments. This is behavior-preserving since the marker was never actually applied before.
• When a marker is configured, it's matched against the line's raw prefix before unquoting, so an enclosed "#x" is data and only an unquoted line beginning with the marker is skipped (composes with LINES STARTING BY, skips consecutive comment lines).
• Since the marker no longer shares the tokenizer byte stop-sets, # is a valid field terminator again (DDL no longer rejects it).

Verified no regression from the global default change: load_data 871/871 and the full stage dir 1411/1411 pass, plus the two writable BVT files (160/160 + 123/123). New csvparser unit tests cover the empty-marker, raw-prefix-match, and all-empty-row-no-panic cases.

[Copilot]

Pull request overview

Copilot reviewed 42 out of 43 changed files in this pull request and generated 7 comments.

Files not reviewed (1)

• pkg/pb/pipeline/pipeline.pb.go: Generated file

[XuPeng-SH]

I rechecked the latest head (66526fa351aeaf4dc149f229ea3ced7b1f15237b). I think a few correctness blockers still need changes before this can land.

1. Writable CSV external tables with a configured comment marker can silently drop rows written by this same feature. The reader now passes plan.GetCSVComment(extern) into CSVConfig (pkg/sql/colexec/external/types.go:291), and the CSV parser skips a record when the raw line prefix matches the comment marker before LINES STARTING BY is stripped (pkg/sql/util/csvparser/csv_parser.go:568). However, the writer config rebuilt by buildExternalInsertArg does not carry this marker (pkg/sql/compile/operator.go:989, pkg/sql/colexec/externalwrite/writer.go:50), and validateWriteFilePattern does not reject it. For example, with comment='1', inserting a row whose first field serializes as 1 writes 1,...\n, and a later read treats it as a comment. With LINES STARTING BY 'R>' and comment='R'/comment='R>', every writer-produced row can be skipped. Please either reject non-empty COMMENT for writable external tables or make the writer guarantee that the raw record prefix cannot match the configured comment marker.

2. SHOW CREATE still drops the external CSV comment option. formatInfileExternalOptionsForShowCreate emits filepath/compression/format/jsondata/write_file_pattern for writable infile tables (pkg/sql/plan/build_show_util.go:961), and formatS3ExternalOptionsForShowCreate has the same gap for S3 options (pkg/sql/plan/build_show_util.go:1000). Since reader semantics now depend on comment (pkg/sql/plan/utils.go:2054, pkg/sql/colexec/external/types.go:291), replaying SHOW CREATE or restore DDL changes what rows are returned.

3. Generated columns are accepted on writable external tables but are not protected or recomputed in the legacy external INSERT/LOAD path. The writable-table validator rejects auto_increment but not GeneratedCol (pkg/sql/plan/build_ddl.go:6038). The external INSERT path uses the minimal legacy builder (pkg/sql/plan/build_insert.go:265) where getInsertColsFromStmt includes generated columns by default (pkg/sql/plan/build_insert.go:375), bypassing the normal binder logic that rejects explicit generated columns and recomputes generated expressions (pkg/sql/plan/bind_insert.go:1108, pkg/sql/plan/bind_insert.go:1435). LOAD into writable external tables similarly uses the legacy project-building path (pkg/sql/plan/build_load.go:521) instead of the modern generated-column filtering in bind_load.go (pkg/sql/plan/bind_load.go:85). This can allow arbitrary values to be stored for generated columns, or store NULL/defaults when the generated column is omitted. Please reject generated columns for writable external tables or route this path through the generated-column rewrite.

Also, the current PR checks show Matrixone Utils CI / Coverage failing.

Local verification note: I tried focused Go test commands for the touched CSV parser/external writer packages, but this checkout fails during build on github.com/unum-cloud/usearch/golang cgo symbols before the tests run, so I could not get a clean local test signal.

[fengttt]

I found a few remaining unhappy-path/correctness blockers in the current head.

1. Compressed writable tables can be created, but the write path always emits plain bytes. validateWriteFilePattern accepts COMPRESSION='gzip' and compressed write-path suffixes, while buildExternalInsertArg/WriterConfig do not carry compression and externalWriter streams raw CSV/JSONLine. The read path later calls crt.GetUnCompressReader(..., param.Extern.CompressType, param.Fileparam.Filepath, ...), and crt.GetCompressType auto-detects suffixes like .gz/.bz2/.lz4 when compression is empty/auto. So a table can be created with a gzip compression setting or a .gz write pattern, INSERT can succeed, and then SELECT tries to decompress raw CSV/JSONLine and fails. Please either implement compression on the write path or reject writable external tables whose effective compression for produced files is not none.
2. CSV comment handling can corrupt valid writer output. External CSV readers always set Comment: '#', and csvparser.readRecord skips any row whose recordBuffer[0] == '#' after quotes are stripped but before unescape. The writer emits "#lost",1\n for a first-column string value '#lost', so the same table can silently drop the inserted row on readback. There is also a panic edge case here: if all fields are empty strings, e.g. ""\n or "",""\n, recordBuffer is empty and the comment check still indexes recordBuffer[0]. Please either disable comment processing for these external table reads, or make the writer/validator protect/reject the affected values; coverage should include leading # and all-empty string rows.
3. Writable DDL accepts CSV delimiter configs that the reader refuses at open time. For example, FIELDS TERMINATED BY '#' passes the new writable validation, but the actual CSV parser rejects it because the reader's comment marker is also #. Delimiters starting with invalid parser bytes such as newline, carriage return, or quote are the same class of issue. This means the table can be created and written, but any read fails before parsing. Writable DDL should mirror the parser delimiter validation or construct/check the parser config during validation.
4. Duplicate external options can make validation check a different configuration than the one later stored/executed. validateWriteFilePattern uses getRawOption, which returns the first format/jsondata, but the option initializers later walk the whole slice and later duplicates win. A table can therefore validate as format='csv' and then be stored/executed as format='parquet', causing runtime external write format "parquet" after CREATE succeeded. Duplicate jsondata can similarly validate as object but read as array. Please reject duplicate option keys relevant to writable external tables before validation/normalization.

All fixed and resolved.

[XuPeng-SH]

I rechecked the latest head (c604e3919093652626d9d09a83bc2b4fa0675c82). The previous generated-column rejection and COMMENT/SHOW-CREATE plumbing are moving in the right direction, but I still see correctness blockers.

1. COMMENT is still unsafe for writable tables; several accepted configurations make the table skip rows it just wrote. The reader applies the comment marker to the raw line prefix before LINES STARTING BY is consumed (pkg/sql/util/csvparser/csv_parser.go:568), and newCSVParserFromReader passes that marker for all formats, including jsonline (pkg/sql/colexec/external/types.go:291). The jsonline writer always starts a record with LineStartingBy + { and has no comment guard (pkg/sql/colexec/externalwrite/encode.go:315), while DDL still allows COMMENT on writable jsonline tables (pkg/sql/plan/build_ddl.go:5998). So format='jsonline' + COMMENT='{' drops every inserted row on readback.

   The CSV-side guard is also incomplete. It only runs for non-NULL, currently-unquoted first fields (pkg/sql/colexec/externalwrite/encode.go:59, pkg/sql/colexec/externalwrite/encode.go:96), and firstFieldStartsComment intentionally returns false when the marker is contained in the fixed LINES STARTING BY prefix (pkg/sql/colexec/externalwrite/encode.go:153). Examples that still corrupt data: COMMENT='REM' LINES STARTING BY 'REM:' skips every writer row; COMMENT='"' skips rows whose first column is always quoted (varchar, enum, bit, json, or numeric/date values that need enclosure); and COMMENT='\N'/COMMENT='\' skips rows whose first column is NULL because the NULL sentinel is written before the guard. Please reject unprotectable COMMENT configurations at DDL time (or reject COMMENT for writable jsonline) and make the CSV writer error/guard for NULL and already-quoted first-field collisions.

2. A failed parallel statement can still leave successfully closed sibling files visible. insert_external finalizes each operator's file as soon as that pipeline sees end-of-input and then nils the writer (pkg/sql/colexec/insert/insert.go:265); Reset/Free only abort a writer that is still non-nil (pkg/sql/colexec/insert/types.go:127, pkg/sql/colexec/insert/types.go:159), and externalWriter.Close finalizes the file (pkg/sql/colexec/externalwrite/writer.go:208, pkg/fileservice/file_service_writer.go:86). In a multi-pipeline INSERT/LOAD, one scope can finish and close a complete output file before a sibling scope later hits an expression/read/write error. The statement returns failure, but the already-closed file remains in the stage; retrying the statement then duplicates that scope's rows. The earlier abort-on-live-writer fix covers partial live streams, but not completed sibling streams in the same failed statement. This needs a statement-level commit/abort strategy, or a way to keep produced files temporary until all parallel writers have succeeded.

3. SHOW CREATE still does not faithfully round-trip LINES TERMINATED BY '\r\n'. The formatter maps both stored "\n" and stored "\r\n" to LINES TERMINATED BY '\\n' (pkg/sql/plan/build_show_util.go:626), while the read/write configs do preserve and honor CRLF (pkg/sql/colexec/external/types.go:277, pkg/sql/compile/operator.go:1023, pkg/sql/colexec/externalwrite/encode.go:333). Replaying SHOW CREATE changes the external-table format from CRLF to LF, so writable tables are still not exact-format recreatable for this supported option.

Also, the latest checks still show Matrixone Utils CI / Coverage failing.

Local verification note: I tried focused tests for csvparser, externalwrite, and plan, but this checkout still fails during build on github.com/unum-cloud/usearch/golang cgo symbols before tests run, so I could not get a local assertion signal.

[fengttt]

I rechecked the latest head (c604e3919093652626d9d09a83bc2b4fa0675c82). The previous generated-column rejection and COMMENT/SHOW-CREATE plumbing are moving in the right direction, but I still see correctness blockers.

1. COMMENT is still unsafe for writable tables; several accepted configurations make the table skip rows it just wrote. The reader applies the comment marker to the raw line prefix before LINES STARTING BY is consumed (pkg/sql/util/csvparser/csv_parser.go:568), and newCSVParserFromReader passes that marker for all formats, including jsonline (pkg/sql/colexec/external/types.go:291). The jsonline writer always starts a record with LineStartingBy + { and has no comment guard (pkg/sql/colexec/externalwrite/encode.go:315), while DDL still allows COMMENT on writable jsonline tables (pkg/sql/plan/build_ddl.go:5998). So format='jsonline' + COMMENT='{' drops every inserted row on readback.
   The CSV-side guard is also incomplete. It only runs for non-NULL, currently-unquoted first fields (pkg/sql/colexec/externalwrite/encode.go:59, pkg/sql/colexec/externalwrite/encode.go:96), and firstFieldStartsComment intentionally returns false when the marker is contained in the fixed LINES STARTING BY prefix (pkg/sql/colexec/externalwrite/encode.go:153). Examples that still corrupt data: COMMENT='REM' LINES STARTING BY 'REM:' skips every writer row; COMMENT='"' skips rows whose first column is always quoted (varchar, enum, bit, json, or numeric/date values that need enclosure); and COMMENT='\N'/COMMENT='\' skips rows whose first column is NULL because the NULL sentinel is written before the guard. Please reject unprotectable COMMENT configurations at DDL time (or reject COMMENT for writable jsonline) and make the CSV writer error/guard for NULL and already-quoted first-field collisions.
2. A failed parallel statement can still leave successfully closed sibling files visible. insert_external finalizes each operator's file as soon as that pipeline sees end-of-input and then nils the writer (pkg/sql/colexec/insert/insert.go:265); Reset/Free only abort a writer that is still non-nil (pkg/sql/colexec/insert/types.go:127, pkg/sql/colexec/insert/types.go:159), and externalWriter.Close finalizes the file (pkg/sql/colexec/externalwrite/writer.go:208, pkg/fileservice/file_service_writer.go:86). In a multi-pipeline INSERT/LOAD, one scope can finish and close a complete output file before a sibling scope later hits an expression/read/write error. The statement returns failure, but the already-closed file remains in the stage; retrying the statement then duplicates that scope's rows. The earlier abort-on-live-writer fix covers partial live streams, but not completed sibling streams in the same failed statement. This needs a statement-level commit/abort strategy, or a way to keep produced files temporary until all parallel writers have succeeded.
3. SHOW CREATE still does not faithfully round-trip LINES TERMINATED BY '\r\n'. The formatter maps both stored "\n" and stored "\r\n" to LINES TERMINATED BY '\\n' (pkg/sql/plan/build_show_util.go:626), while the read/write configs do preserve and honor CRLF (pkg/sql/colexec/external/types.go:277, pkg/sql/compile/operator.go:1023, pkg/sql/colexec/externalwrite/encode.go:333). Replaying SHOW CREATE changes the external-table format from CRLF to LF, so writable tables are still not exact-format recreatable for this supported option.

Also, the latest checks still show Matrixone Utils CI / Coverage failing.

Local verification note: I tried focused tests for csvparser, externalwrite, and plan, but this checkout still fails during build on github.com/unum-cloud/usearch/golang cgo symbols before tests run, so I could not get a local assertion signal.

1. has been fixed/resolved by another two PRs.
2. Is by design, there is no reliably way of controlling files generate by failed export. Usually this is left to external apps.
3. Should be fixed.

Code coverage failure is not related to this PR. I hope OpenAI and Claude will converge :).